#mongoosejs

This should be simple, but Mongoose really clings to data in existing documents. I’ll walk through all the ways I wanted it to work that failed. We’ll remove an organic flag from a toy Food model so we can replace it with Bittman’s dream label. If you just came for the solution, I arrived at:

View gist on GitHub

Our well-loved Food schema might look something like:

View gist on GitHub

and it might be populated with documents like organic frozen broccoli:

View gist on GitHub

Alright, time to get rid of that organic property. Adding a property with Mongoose is as easy as declaring it in the schema. Could removing be just as easy?

View gist on GitHub

If we reload our broccoli doc, will mongoose strip out the undeclared properties? We did tell Mongoose to be strict with our Food…

View gist on GitHub

No. Too slick. I suppose it’s comforting that mongoose isn’t silently manipulating our docs. Maybe we just need to re-save broccoli. Surely mongoose will be 

View gist on GitHub

Nope. Mr. Heckmann rationalizes this behavior as

Mongoose “plays nice” with existing data in the db, not deleting it unless you tell it to.

I’ll have to be more explicit with this broccoli, more meticulous with my cleanup. I’ll unset organic directly.

View gist on GitHub

Wow. Fine. Now strict decides to help out.

Mongoose isn’t cooperating. Time to talk directly to Mongo. Maybe Mongoose can at least offer me some update sugar:

View gist on GitHub

This must be strict still keeping us safe.

Okay. Last chance Mongoose. Just give me the collection.

View gist on GitHub

Phew.

NodeJS has become a prominent part of my development stack over the last few months, as has MongoDB. The folks from Learnboost have created several great NodeJS packages, one of which is MongooseJS. Mongoose is a MongoDB wrapper that helps developers define schemas or data objects stored in MongoDB. Though the library is powerful and pretty feature rich, there isn't much written on best practice use of it. I've decided to share my approach in hopes of sparking discussion around this topic.

For those who aren't familiar with Mongoose, it is a NodeJS wrapper around MongoDB. Being a NoSQL document store, MongoDB has no defined data structure. For those coming the world of SQL, this can be a bit alarming. Mongoose adds a data integrity layer to applications through the use of Schemas. A schema can be but isn't necessarily a "database" or "table" within MongoDB. However; this is really outside the scope of this article. Head over to the MongoDB site and lookup collections or the Mongoose website for more information.

If you're familiar with Mongoose, you know it's possible to define many Schemas in a single JavaScript file. For small applications, this isn't a big deal. However; handling a lot of schemas can get confusing with no organizational pattern.

Personally, I liked the idea of keeping my schemas organized in a one-schema-per-file manner where the file is named in representation of the data it represents. This helps isolate schema logic and keep it in the context of a single file. Furthermore, you can simply look in a single directory to see the schemas.

To accomplish this, I created MDB, available freely on my Github page.

MDB handles a lot of common stuff. For example, it supports connecting to single MongoDB instances or replica sets, it auto-includes and registers schema models, and I've added autoconnect, debugging, custom and generic errors, and connection timeouts... all wrapped up with some sugar syntax.