Book Image

Learning Mongoid

By : Gautam Rege
Book Image

Learning Mongoid

By: Gautam Rege

Overview of this book

Mongoid helps you to leverage the power of schema-less and efficient document-based design, dynamic queries, and atomic modifier operations. Mongoid eases the work of Ruby developers while they are working on complex frameworks. Starting with why and how you should use Mongoid, this book covers the various components of Mongoid. It then delves deeper into the detail of queries and relations, and you will learn some tips and tricks on improving performance. With this book, you will be able to build robust and large-scale web applications with Mongoid and Rails. Starting with the basics, this book introduces you to components such as moped and origin, and how information is managed, learn about the various datatypes, embedded documents, arrays, and hashes. You will learn how a document is stored and manipulated with callbacks, validations, and even atomic updates. This book will then show you the querying mechanism in detail, right from simple to complex queries, and even explains eager loading, lazy evaluation, and chaining of queries. Finally, this book will explain the importance of performance tuning and how to use the right indexes. It also explains MapReduce and the Aggregation Framework.
Table of Contents (14 chapters)
Learning Mongoid
About the Author
About the Reviewers

has_and_belongs_to_many – the many-to-many relation

Let's assume that books belong to many categories and categories have many books. This is the Many-to-Many relationship method. A typical class would look like the following:

class Book
  include Mongoid::Document

  has_and_belongs_to_many :categories

class Category
  include Mongoid::Document

  has_and_belongs_to_many :books

It takes all the standard options such as :autosave, :dependent, :foreign_key, :index, :primary_key, and :order. It also supports the :before_add, :after_add, :before_remove, and :after_remove relation callbacks.


A Many-to-Many relation cannot be a part of a polymorphic relation. This is because a polymorphic relation expects an explicit parent-child relationship and Many-to-Many relations are peer relations.


Among all the other options, the inverse_of relation is a very interesting one. As with Many-to-Many relations, the document IDs are stored as arrays on both sides of the association. So...