Ability to set object level databases and collections #465

Open
wants to merge 1 commit into
from

Projects

None yet

4 participants

@aparmar
aparmar commented Oct 16, 2012

Added the ability for objects of the same class to have different databases or collections.

@aparmar aparmar ability to set object level databases and collections
Added the ability for objects of the same class to have different
databases or collections.
6a622a3
@jnunemaker
Contributor

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?

@aparmar
aparmar commented Oct 16, 2012

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"
http://mongoid.org/en/mongoid/docs/persistence.html

@almathie

I'd really love to see this merged into master

@cheald
Member
cheald commented Jul 6, 2013

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.

@cheald
Member
cheald commented Jul 6, 2013

Here's my go at it:

cheald@0c770f6

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment