Added the ability for objects of the same class to have different databases or collections.
ability to set object level databases and collections
Added the ability for objects of the same class to have different
databases or collections.
This makes the class level finder's kind of worthless, which would be confusing to a new developer on a project that does this. How are you handling that?
The idea is to have overrides. The hierarchy (before the patch) lets us define a global database, a class level database but not an object level database. This patch allows that. Just like your default code, if the override doesn't exist, it defaults to the class. And if the class override doesn't exist it defaults to the global.
It similar to Mongoid's persistance keyword "with" which lets you change at "runtime where to store, query, update, or remove documents"
I'd really love to see this merged into master
I'd just use the Mongoid syntax, honestly - that gets you the usefulness of the feature without making the fact that it's there opaque to the developer.
This could be done cleanly by abstracting the stuff in the Querying plugin out into its own class, which the Querying plugin would instantiate and call. This would let a WithPersistenceOptions method instantitate its own subclass of the Querying interface class and override the necessary attributes. This would get you things like:
Doc.with(database: "foo", collection: "bar").where(:baz => "bin").first
The plugin would also override the #collection and #database instance methods on the record so they are pointed appropriately.
Here's my go at it:
The syntax is straight from Mongoid:
Doc.with(:db => "foo", :collection => "bar").create(:name => "whee!")
Doc.with(:db => "foo", :collection => "bar").where(:name => "whoo!").first
Doc.where(:name => "whoo!").with(:db => "foo", :collection => "bar").first # Also works!
etc etc. Seems to work fine, and it's all done via the plugin. Worst case, we could ship it without it enabled and let people enable it as desired.
It's worth noting that I think the plugin architecture needs a load order mechanism, like Rack, because many plugins are load order dependent. Something like:
plugin MongoMapper::Plugins::WithPersistenceOptions, :before => MongoMapper::Plugins::Sci
This would let us ship plugins that are load-order-dependent and off by default and still let people turn them on at will.