Using Mongo Native + Node.js

With Mongoose in the land of Star Wars 7 and universal USA health care, its worth looking at how to use MongoDB native. While it is a bit raw, you have full access to the Mongo toolkit and with its low-level access to Mongo commands its worthwhile learning even if you hope to use Mongoose to design your golden submarine or whatever. While there are a few other libraries in Git I'd recommend the Christkov MongoDB library, if for no other reason than to take advantage of the testing being done by LearnBoost. 

Installation

There are two ways to install this library. One is to use NPM 

npm install mongodb

and the other is to simply download the library and stick it in your project somewhere (typically [root]/lib/mongodb-native, and this is the pathing I'll use in this article.) I reccommend the latter route for two reasons:

1. You don't have to worry about whether your deployment version is different than your development version
2. You can easily echo and log the Christkov library during development if its in your project

Along with these choices you have two other variations of using this library: 

1. the "Pure" path - short for "pure javascript" - doesn't use the c libraries. 
2. the "Native" path uses c libraries for faster connection. 

This option is made in the method that retrieves a database. Among the options of the third parameter of the method that retrieves the database is a parameter "nativeParser" which accepts boolean (true/false) values. 

The below call, retrieving a database named 'noogle', takes the "pure" path. 

var database = new mongo.Db('noogle', new mongo.Server('localhost', 27017, {}), {
                native_parser: false
            });

A Crash Course in Mongo

The most difficult thing about MongoDB is how simple it is. Mongo (like Couch) is a repository that allows you to store random clumps of JSON in named collections. Unlike a database, Mongo documents MUST have an _id property. If you don't actively set the _id value of your JSON* document, one is supplied for you.**

Mongo collections don't -- can't -- have a native schema. In contrast to database tables with a rigid set of fields, each with complex criteria(type, size, required/optional, nullable) there is no native template in Mongo for a given document. Most especially, there is no requirement for a given document's format based on the collection it belongs to, OR the structure of any other documents in the given collection. A document can contain any structure you care for, and in fact documents in the same collection can vary from document to document. This includes nesting: you can have, in a given document, a very deep tree with arrays of objects, containing arrays or objects, containing arrays or objects or values... You can see this as freedom or a license to hang yourself, but thats how it is. Here is one sample document - that being the structure of a single line of chat from an IRC channel. 

{ "_id" : ObjectId("4d3ddd0539319ac03d0a32b2"), "index" : 577, "time" : "22:39",
 "text" : "the_undefined: jumping between interface builder and xcode is pain",
 "words" : [
"jumping",
"between",
"interface",
"builder",
"and",
"xcode",
"is",
"pain"
], "nick" : "the_undefined", "url" : "http://nodejs.debuggable.com/2009-11-26.txt" }

As alien as this is from the SQL perspective most of the basic access methods in Mongo should be familiar: find, update, insert, drop, ensureIndex. The use of these methods is of course distinct, but their basic impact is pretty straightforward. I'll be going over them in detail, to illustrate their use and abuse in Node.js. 

Data Types

While there aren't the wild range of data types in Mongo, there are data types more complex than numbers and strings.

• The most common one is the ObjectId, which if you plan to create them manually must be done so using custom classes in Node.
• Boolean (true/false) values translate directly to their javascript equivalents. 
• Date (MongoDate) data is timezone-agnostic (GMT) based.
• custom geolocation storage formats are also available. (don't actually use them, so DIY)
• Lastly, though not a field format in the strictest definition of the word, large chunks of binary or text data can be saved in a seperate, special collection maintained by the GridFS 

As with JSON, a wide range of combinations of arrays and objects can be used to store values. Properties are case-sensitive. 

*Technically Mongo stores information in BSON, a binary format, but the differences between BSON and JSON aren't that important in daily use. 

**Unlike the typical SQL table, the ID is not an integer - its not even a string at all, but a native special purpose class called an ObjectID. See the documents for detail.