MongoDB CRUD: Part II

Welcome to part two of our excellent adventure. Before we resume, let's seed our database with some more documents to play with.

var max = 33;
while (max--) {
    db.stomach.insert({
        name: 'Oreo',
        part: max % 3 === 0 ? 'white' : 'black'
    });
}

Update

Now that we've got a bunch of Oreos in our stomach collection, I don't think the Sweetwater we added in Part I was such a good idea. Let's change it.

1. Find the documents we want to update. We'll do that with another query.
2. Specify the new values. That's done with the update parameter.

db.stomach.update(
    // query
    { beer: 'Sweetwater' },

    // update parameter
    {
        $set: {
            beer: 'root'
        }
    }
);

We changed the document's beer value from 'Sweetwater' to 'root'. This did not affect the other fields in the document, as you can see.

db.stomach.find({
    beer: {
        $exists: true
    }
}).pretty();

{
    "_id" : ObjectId("5424a5ba28f262081e997a7f"),
    "beer" : "root",
    "count" : 2
}

What if we want to completely replace the fields in the document, though? Who wants rootbeer with cookies? Let's make it more complimentary to the other documents in the collection.

db.stomach.update(
    // query
    {
        beer: {
            $exists: true
        }
    },

    // update parameter
    {
        drink: 'milk',
        type: 'skim',
        ounces: 8
    }
);

By specifying a plain object as the update parameter instead of update operators, we've completely changed the document.

> db.stomach.find({ drink: 'milk' }).pretty();
{
    "_id" : ObjectId("5424a5ba28f262081e997a7f"),
    "drink" : "milk",
    "type" : "skim",
    "ounces" : 8
}

Note that the _id does not change when using update, even when replacing the document.

Now, let's change all those old-fashioned Oreos to one of the new flavors.

db.stomach.update(
    // query
    {
        name: 'Oreo',
        part: 'white'
    },

    // update parameter
    {
        $set: {
            part: 'berry'
        }
    }
);

Let's see the results.

> db.stomach.find({ name: 'Oreo', part: 'berry' }).pretty();
{
    "_id" : ObjectId("542603ba21330a1f47f4bd68"),
    "name" : "Oreo",
    "part" : "berry"
}

Only one of the documents was updated. This brings us to the 3rd parameter of update, the options. The options are described in the documentation, one of which is multi.

db.stomach.update(
    // query
    {
        name: 'Oreo',
        part: 'white'
    },

    // update parameter
    {
        $set: {
            part: 'berry'
        }
    },

    // options
    {
        multi: true
    }
);

> db.stomach.find({ name: 'Oreo', part: 'berry' }).count();
11

By default, update only modifies a single document. With multi, we can make it update all the documents matched by our query.

Delete

Now we've got a stomach collection full of berry cookies and milk, the anchovy pizza isn't really sitting well. Let's barf it up.

db.stomach.remove({
    anchovies: {
        $exists: true
    } 
});

That should seem pretty intuitive by now.

References

• MongoDB Update
• MongoDB update operators
• MongoDB Remove
• MongoDB db.collection.remove()

---

Check out the accompanying Github repo to these posts about MongoDB/Mongoose.

MongoDB CRUD: Part I

In a previous post, I wrote the "M" in MEAN really stands for Mongoose as it is the de facto way to work with MongoDB. However, it's interesting to peek beneath the surface. You don't have to be able to rebuild a manifold in order to drive, but you should probably know how to check the oil.

So, now that we know how to connect, let's figure out how to CRUD documents.

Create

Databases contain collections. Collections contain documents. To insert a new document into a collection, we use the insert method.

db.stomach.insert({
    crust: 'thin',
    pepperoni: true,
    olives: true,
    anchovies: 6
});

Easy, right? That inserted a pizza-like document into the stomach collection. Let's try it again.

db.stomach.insert({
    beer: 'Sweetwater',
    count: 2
});

Pretty straightforward. Also, this demonstrates why NoSQL databases are so cool; documents within a collection don't have to have to the same fields. Collections are like tables, but friendlier. Do you remember going into admin mode and creating the stomach table before we ran these queries?

Exactly.

Read

Now that's we've got a collection and a couple documents, let's see about reading them. What was our collection's name again?

> show collections
stomach
system.indexes

Oh, yeah, stomach. Let's see what's in there.

> db.stomach.find().pretty();
{
    "_id" : ObjectId("5424a39628f262081e997a7e"),
    "crust" : "thin",
    "pepperoni" : true,
    "olives" : true,
    "anchovies" : 6
}
{
    "_id" : ObjectId("5424a5ba28f262081e997a7f"),
    "beer" : "Sweetwater",
    "count" : 2
}

As you can see, MongoDB inserted a unique _id for us because we didn't include one.

find can take a couple arguments to make it more useful.

• an object of query operators - This specifies what documents you're looking for.
• an object of projection operators - This specifies what fields you want returned in the results.

db.stomach.find(
    {
        anchovies: {
            $exists: true
        }
    },

    {
        crust: 1,
        pepperoni: 1,
        donkey: 1
    }
);

I'm not going to go over all the options as the documentation is very good, but you get the idea. A couple notes, though.

• It's worth noting that find returns a cursor that you can iterate through to see the returned documents. Because we didn't assign the expression to a variable, mongo printed out the first 20 results automatically.
• _id is returned unless you explicitly exclude it in the projection. You can't mix includes and excludes in your projection with the exception of the _id field.
• We included donkey in the projection, but it doesn't exist. Therefore, it was not in the result.

Summary

My wife just turned on Bill a Ted and it's surprisingly distracting. That means, Update and Delete will come in part II of this post. Party on, dudes!

References

• From within mongo, just type help. It's very good.
• MongoDB CRUD operations
• MongoDB Glossary
• MongoDB Create
• MongoDB Read
• mongo shell reference

---

Check out the accompanying Github repo to these posts about MongoDB/Mongoose.

Connecting to MongoDB

Connecting to MongoDB with Mongoose is really easy.

mongoose.connect('mongodb://localhost/my-cool-database');

Suppose you want to poke around your database outside of Mongoose, though. How do you connect? Use mongo, the shell interface.

Basic Connection

This connects to the "test" database on "localhost".

mongo

Another Machine/Database

You can specify a different machine and/or database by specifying the "database address."

# connect to another database (on localhost)
mongo some-other-db

# connect to another machine/database
mongo whatever.com/some-db

Warning

You can connect to a machine without specifying a database, but this is NOT how to do it.

mongo localhost

This will connect you to "localhost" using the database "localhost." If you want to connect without automatically selecting a database, use the --nodb option.

mongo localhost --nodb

From there, you can connect to a database manually.

Change Port

By default, MongoDB runs on port 10027. If you're running on a different port, just include that in the "database address."

mongo whatever.com:12345/some-db

Close Connection

Now you can connect to your MongoDB in a few different ways. Since we haven't covered anything else yet, the final thing you need to learn is how to disconnect. Baby steps, right?

You can close the connection with exit or ctrl + c.

---

Check out the accompanying Github repo to these posts about MongoDB/Mongoose.

IIFE Mania

At work today, I noticed someone using an IIFE that was completely pointless. The only possible rationalization was, "I saw it on SO and don't really understand JavaScript." So, allow me to elucidate.

An IIFE creates a tidy new scope for you to do your magic in. This is especially good if you're creating modules.

Protecting Global Namespace

The scope created can act like a safety net to keep you from accidentally declaring global variables. Implied globals, however, slip right through. That's cool, but your linter should catch these mistakes.

non-IIFE

// blatant new global variable
var foo = 1;

// an implied global
bar = 1;

IIFE

(function () {
    // foo stays out of the global namespace
    var foo = 1;

    // implied globals are still global
    bar = 1;
}());

console.log(bar);

Passing Arguments

Perhaps my colleague thought passing arguments into his function provided some benefit. Though, the arguments passed in were globals we provide. It's not a $ conflict situation.

This is the aspect that really made me scratch my head.

Does passing arguments somehow protect them? No, because they're the same reference.

var foo = { original: true };

(function (localFoo) {
    console.log(localFoo === foo);  // true
    console.log(localFoo.original); // true
}(foo));


// evil code messing up our precious global
foo.original = false;

As long as your function executes before that other evil code messes with the global, you're good. But wait...

var foo = { original: true };

console.log(foo.original); // true

// evil code messing up our precious global
foo.original = false;

That gets you the same result since your code executed before the evil code.

What if you're trying to insulate the outside world from your changes to the globals?

var foo = { original: true };

(function (foo) {
    foo.original = false;
}(foo));

console.log(foo.original); // false

Oh, yeah. They're the same reference. There's no benefit to passing these in.

Why Ever Pass Arguments?

There are a few situations where it's a good idea to pass arguments into an IIFE.

Aliasing

If you want to use a different name for the global, that's cool. This is how jQuery gets around other libraries that use $. It's a nice way for you to pick what you want to call the global.

This example attempts a lame joke by reference.

var foo = { original: true };

(function (al) {
    console.log(al.original);
}(foo));

Super Fast Code

Another good time to pass arguments into your IIFE is when you've optimized every other frigging thing in your code and you just have to speed it up some more. Technically, providing the parameter creates a reference to the global variable inside the function's scope. That means, wherever your code references the global, it won't have to look up the scope chain until it finds it in the stratosphere.

That's kind of a stretch, though.

Conclusion

IIFEs have a proper place, including those with arguments. Primarily, it's to carve out a nice private chunk of scope for you to work in. If you're not declaring any variables or functions, you don't need this.

Passing arguments into an IIFE looks really cool like all the stuff you've seen online, but there aren't many reasons to do it. If you do it when it's pointless, it just makes you look like a jackass.

The Lazy Way to Write a Blog

start 8:42 pm

I rarely find time to sit down and write a blog. When I do, it's annoying how much time is wasting using this clunky WYSIWYG. It's not perfect, but here's what I've come up with to stream line the process.

Use Sublime

Screw writing in the browser. I live in ST3, so why not stay there?

Use Markdown

Writing HTML is for chumps; use Markdown.

Use Markdown Preview

Install the Makdown Preview package. When you're done previewing and want post your blog, use ctrl + shift + p, "Markdown Preview: Copy to Clipboard". Select the github option.

Create a new file, paste the contents, and delete everything except the body content. It will be a little unreadable, with lots of styles, but it's not hard to search for the body tag. You're in Sublime, right?

<!DOCTYPE html><html><head><meta charset="utf-8"><style></style> <title>blah</title></head><body><article class="markdown-body"><p>blah blah blah</p></article></body></html>

Take the remaining content and paste it into your blog.

Add the CSS

In Blogger, and probly other blogs, you can add global CSS for your pages. Use this CSS, which is the same stuff you just clipped out of your preview in the step before.

Summary

Now, you can crank out blogs that look reasonably well. The important thing for me is how code snippets look.

(function () {
    'use strict';

    var formatted = true;

    console.log('They look ' + (formatted ? 'good' : 'crappy') + '.');
}());

So, that's it. I haven't quite figured out how to deal with images, but this isn't bad. As you can see, including looking up references, it only took 21 minutes to write this.

end 9:03 pm

Hello, MongoDB

Update: Check out the accompanying Github repo to these posts about MongoDB/Mongoose.

---

Learning the MEAN stack is fun, especially Node and Angular.  There's a lot to get into just in those two parts, but eventually you're going to want to save some data.  (If not, try out my npm module that fakes persistence.)

So let's learn about the "M."

MEAN is supposed to be MongoDB, Express, AngularJS, and Node, but the "M" really seems to stand for Mongoose, a modeling system.  It's MongoDB underneath, but you don't really have to deal with it directly.

Mongoose Essentials

Define a Schema

The schema describes the object you're going to work with.

var mongoose = require('mongoose');

var dudeSchema = mongoose.Schema({
    name: String,
    age: Number,
    height: Number,
    isMale: Boolean
});

Create a Model

Use your schema to create a model.

var Dude = mongoose.model('Dude', dudeSchema);

Use the Model for CRUDing

var gw = new Dude({
    isMale: true,
    name: 'George Washington'
});

gw.save(function (err, run) {
    if (err) {
        res.status(500).send(err);
    } else {
        res.json(run);
    }
});

This is just the very basics to help you get your bearings.  We'll get more complex later.

references

http://mongoosejs.com/docs/index.html

$scope or this?

Why is it that the Angular JS docs use $scope in controllers and not this?

It's because they're not the same thing.  The scope that is injected into the controller is prepared before the controller is created.

During the compilation phase, DOM elements, nodes, with directives are found.  Then different types of linking functions are created for each of the nodes based on if the nodes have children or not.

During the linking phase, Angular loops through all of the nodes and links them, pairs them up with a scope.  The `nodeLinkFn` then creates the scope, either brand new or inherited from an outer scope.

childScope = scope.$new();

jqLite attaches this new scope to the node.

jqLite.data(node, '$scope', childScope);

Then, based on the type of linking function that was created, the scope is then tied to the controller.

// locals is a bunch of attributes for the controller, including $scope
controllerInstance = $controller(controller, locals);

$controller is a service that is used to look up the controller we're asking for.  The controller definitions were already created, this just looks up the injected stuff and the constructor function.  Then the injection happens.

instance = $injector.instantiate(expression, locals);

During the instantiation, the constructor function's prototype, the one we wrote, is assigned to the new `Constructor` object's prototype.  Then a new `Constructor` instance is created.  This is all really just standard JS inheritance footwork.  The next part is what we've been waiting for.

`invoke` is called, which actually injects the dependencies into our shiny new object.  This is how the '$scope' dependency we referenced when writing our controller gets set up to be the `$scope` argument within our function.  Finally, our function is called with the new polished `Constructor` instance as its scope.

// fn is the function we injected
// self is the new Constructor object
// args are all the prepared dependencies
return fn.apply(self, args);

So, we're finally inside the controller from our perspective.  Now it should make some sense.

app.controller('FooCtrl', ['$scope', function ($scope) {
    // `this` is the new Constructor object.
    // `$scope` is the scope our controller is tied to the directive with.

    this.message = 'I will not be available to directives.';
    $scope.message = 'I will be.';
}]);

This highlights something, though.  If `$scope` is the context in which the directive is tied to the controller, isn't `this === $scope` within methods of the controller?  Also, `this` is used for inheritance, `$scope` is used for communicating with the directive, what about this gap that local variables live in?

app.controller('FooCtrl', ['$scope', function ($scope) {

    // Local variables can hide out here safely.
    var privateMessage = 'I am available through a closure.';

    // This is pointless.  We're adding `message` to the Constructor object.  Pretty dumb.
    this.message = 'I will not be available to directives.';

    // Being well-behaved, we use $scope like it taught us to in the docs.
    $scope.message = 'I will be available.';

    // Controller methods are called within the context $scope.
    $scope.doClick = function () {
     
        // You could use `this`, but it may lead to confusion.  With all the trickiness,
        // wouldn't it be better to be explicit?
        // $scope === this
        this.message = privateMessage;
    };
}]);

OK, I feel better.  We're going to keep using $scope, but now we'll know why.