Mongoid store_in produces random results

Question

I am using Rails 3.2.2 with mongoid 2.4.6. In order to keep my collections small I am storing child objects to a base class in sepparate collections using the "store_in" statement. My code looks like this:

class BaseClass
  include Mongoid::Document
end

class ChildClass1 < BaseClass
  store_in :child_1
end  

class ChildClass2 < BaseClass
  store_in :child_2
end

It appears that the objects get randomly stored in or or the other child collection. An object of type Child1 sometimes gets stored in collection Child2. Here is the surprising thing that I see in my logs:

Started POST "/child_class_1" for 127.0.0.1 at 2012-05-22 10:22:51 -0400
Processing by ChildClass1Controller#create as HTML

MONGODB (0ms) myproject_development['child_2'].insert....

Where does that come from? Is this a bug in mongoid, rails or mongodb?

Answer 1

It took me a while but I figured the answer out. I decided to post it, hoping it will help others.

Mongoid implements something that is called "single table inheritance". As soon as you derive a child class from a parent class, the child would be stored in the parent collection adding a "type" attribute. Using "store_in" tells mongodb explicitly which collection to store documents in. Defining the store_in in the child class makes mongoid store everything (incl. the parent) in the given collection. I guess using a dedicated store_in assignments for each child messes mongoid up. However, the result is that documents get stored randomly in any of the given collections.

This can be solved in Ruby using a module as mixin for the common functionality. This is described pretty well in this document.

BUT I decided not to do this after all! The reason why I wanted this is in order to keep my collections small, hoping to get better performance. After talking to some (10gen) experts I think the better approach is to use the single parent object collection for all child elements. There should be no impact on the performance of mongodb but the solution becomes much more flexible. In fact this makes much better use of the schemaless design in mongodb.

So the code will look like this again:

class BaseClass
  include Mongoid::Document

  ... shared functionality

end

class ChildClass1 < BaseClass
  ...individual functionality...
end  

class ChildClass2 < BaseClass
  ...individual functionality...
end