Learning Mongoid: If you know MongoDB and Ruby, then Mongoid is a very handy tool to have at your disposal. Quickly learn to build Rails applications with the helpful code samples and instructions in this book.

First and foremost, we need to ensure that we have our development environment set up. It's common to use multiple versions of Ruby for development; I use RVM to manage these versions. As we can have multiple versions of the same gem installed on our machines, we use RVM gemsets to manage the gems we need for our work.

$ rvm list

rvm rubies

   jruby-1.7.4 [ x86_64 ]
   ruby-1.9.3-p385 [ x86_64 ]
=* ruby-2.0.0—p247 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

$ ruby –v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]

$ mongo
MongoDB shell version: 2.4.6
connecting to: test
>

First and foremost, let's install the Rails gem.

$ gem install rails

This installs Rails 4.0.0.

Now, let's create the Sodibee project.

$ rails new sodibee -O -T

This creates a new Rails project. The –O option tells Rails to skip ActiveRecord (we don't need it), and –T tells Rails to skip test unit. (We plan to use rspec later).

Now, open Gemfile and configure for Mongoid.

gem 'mongoid', git: "git://github.com/mongoid/mongoid.git"

We're almost done. Issue the following command to update the bundle with our Mongoid gem:

$ bundle

If you did not use the –O option, you can run the following instructions to remove ActiveRecord from the application as we don't need it. Check and remove database.yml under config, if it has been generated. Next ensure that application.rb under config has the following lines:

require File.expand_path('../boot', __FILE__)

require "action_controller/railtie"
require "action_mailer/railtie"
require "sprockets/railtie"

# Assets should be precompiled for production (so we don't need the gems loaded then)
Bundler.require(*Rails.groups(assets: %w(development test)))

Notice that there is no require "rails/all". This ensures that the ActiveRecord railtie is not loaded. However, sometimes this causes a conflict with the environment settings. So, in case you face a problem starting the Rails console, remove the following line from development.rb under config/environments (and as required from the other environment files):

# config.active_record.migration_error = :page_load

This should get us going. Now issue the following command to set up Mongoid:

$ bundle exec rails generate mongoid:config

This generates mongoid.yml under config.

Test this basic Rails setup by starting the console.

$ rails c
Loading development environment (Rails 4.0.0)
2.0.0-p247 :001 >

If you see the preceding command prompt, we are set.

$ rails generate model Author
# app/models/author.rb
class Author
  include Mongoid::Document
  include Mongoid::Attributes::Dynamic

  field :name, type: String

  embeds_one :address
end

$ rails generate model Address
class Address
  include Mongoid::Document

  field :street, type: String
  field :city, type: String
  field :state, type: String
  field :zipcode, type: String
  field :country, type: String

  embedded_in :author
end

irb> a = Author.create(name: "Charles Dickens")
 => #<Author _id: 5143678345db7ca255000001, name: "Charles Dickens">

irb> a.create_address(street: "Picadilly Circus", city: "London", country: "UK")
 => #<Address _id: 514367f445db7ca255000003, street: "Picadilly Circus", city: "London", state: nil, zipcode: nil, country: "UK">

irb> Author.first
 => #<Author _id: 5143678345db7ca255000001, name: "Charles Dickens">

irb> Author.first.address
 => #<Address _id: 514367f445db7ca255000003, street: "Picadilly Circus", city: "London", state: nil, zipcode: nil, country: "UK">

irb> a['language'] = "English"
 => "English"

irb> a.save
 => true

irb> Author.first
 => #<Author _id: 5143678345db7ca255000001, name: "Charles Dickens", language: "English">

So, let's see what happened in Mongoid and MongoDB. First, let's see what is in the log file development.log under log.

When we issued the command Author.create(name: "Charles Dickens"), it generated the following output:

MOPED: 127.0.0.1:27017 INSERT       database=sodibee_development collection=authors documents=[{"_id"=>"5143678345db7ca255000001", "name"=>"Charles Dickens"}] flags=[] (0.2460ms)

Now, when we issued the second command a.create_address(street: "Picadilly Circus", city: "London", country: "UK"), it updated the Author object, and created an embedded Address document as seen in the following line:

MOPED: 127.0.0.1:27017 UPDATE       database=sodibee_development collection=authors selector={"_id"=>"5143678345db7ca255000001"} update={"$set"=>{"address"=>{"_id"=>"514367f445db7ca255000003", "street"=>"Picadilly Circus", "city"=>"London", "country"=>"UK"}}} flags=[] (0.1211ms)

Now that we have seen what INSERT and UPDATE look like, querying the Author collection with Author.first generates the following result:

MOPED: 127.0.0.1:27017 QUERY        database=sodibee_development collection=authors selector={"$query"=>{}, "$orderby"=>{:_id=>1}} flags=[:slave_ok] limit=-1 skip=0 batch_size=nil fields=nil (66.7090ms)

And since we want to query the address, we look it up using Author.first.address. This generates the following line:

MOPED: 127.0.0.1:27017 QUERY        database=sodibee_development collection=authors selector={"$query"=>{}, "$orderby"=>{:_id=>1}} flags=[:slave_ok] limit=-1 skip=0 batch_size=nil fields=nil (0.5021ms)

Now there's something interesting about the preceding output—the last two commands on the Author model fired the same query, and look at the difference in the query result! The same query is fired because the address is an embedded document. So, to fetch the address of an author, you fetch the Author object itself. The difference of 66 ms and 0.5 ms in the query response is because for the first lookup MongoDB loads the document from the disk and puts it into its memory-mapped file. The second time, the document is simply looked up in cache (the memory-mapped file) and hence the lookup is faster.

  MOPED: 127.0.0.1:27017 UPDATE       database=sodibee_development collection=authors selector={"_id"=>"5143678345db7ca255000001"} update={"$set"=>{"language"=>"English"}} flags=[] (0.1121ms)

irb> a = Author.create(name: "Gautam")
 => #<Author _id: 515085fd45db7c911e000003, name: "Gautam">

irb> a.language = "English"
NoMethodError: undefined method `language=' for #<Author _id: 515085fd45db7c911e000003, name: "Gautam">
  from lib/mongoid/attributes.rb:317:in `method_missing'
  from (irb):12
  from lib/rails/commands/console.rb:88:in `start'
  from lib/rails/commands/console.rb:9:in `start'
  from lib/rails/commands.rb:64:in `<top (required)>'
  from bin/rails:4:in `require'
  from bin/rails:4:in `<main>'

irb> a[:language] = "English"
 => "English"
irb> a.save
 => true

irb> a.language
 => "English"
irb> a[:language]
 => "English"

Origin is a gem that provides the DSL for Mongoid queries. Though at first glance, a question may seem to arise as to why we need a DSL for Mongoid queries; If we are finally going to convert the query to a MongoDB-compliant hash, then why do we need a DSL?

Origin was extracted from Mongoid gem and put into a new gem, so that there is a standard for querying. It has no dependency on any other gem and is a standalone pure query builder. The idea was that this could be a generic DSL that can be used even without Mongoid!

So, now we have a very generic and standard querying pattern. For example, in Mongoid 2.x we had the criteria any_in and any_of, and no direct support for the and, or, and nor operations. In Mongoid 2.x, the only way we could fire a $or or a $and query was like this:

Author.where("$or" => {'language' => 'English', 'address.city' => 'London
'})

And now in Mongoid 3, we have a cleaner approach.

Author.or(:language => 'English', 'address.city' => 'London')

Origin also provides good selectors directly in our models. So, this is now much more readable:

Book.gte(published_at: Date.parse('2012/11/11'))

As we shall see later in the book, Origin has a lot more cool features.