bryan.a.soto at gmail.com
Tue Feb 14 13:13:15 EST 2006
On 2/13/06, zimba.tm <zimba.tm at gmail.com> wrote:
> All applied
> On Monday 13 February 2006 22:41, Bryan Soto wrote:
> > * dispatch_test_case
> > Adds test for NoActionError to tc_dispatch.
> > * prevent_multi_enchantments
> > This patch changes _no_ external behaviour. It only rejects classes
> > already managed in Og::Manager#manage_classes from the collection
> > from Og::Manager#manageable_classes.
> > Also adds a method Og::Manager.managed_classes which returns all
> > actually managed by Og, as opposed to Og::Manager.manageable_classeswhich
> > returns all classes that are capable of being managed. A subtle
> > perhaps, but it bugged me.
> It Og::Manager a singleton class ? Normally Og supports multiple database
> connections. Does it instanciate a new store or a new manager for each
> database ?
No, it's not a singleton. Each call to Og.setup creates a new manager and
defines the way it persists objects. It then walks object space and manages
every single class it can. So currently, if you want multiple stores, you
have to define them in order:
1) Define classes for store #1.
2) Define store #1.
3) Define classes for store #2.
4) Define store #2.
5) Repeat as necessary.
This is how it's worked since I got involved with Nitro/Og.
I hope your patch doesn't break this.
Not at all. :)
It's based off of Og::Manager.managers which just walks object space to find
instances of itself. It then collects the managed classes from each manager
and returns the flattened array.
Trust me, I value multiple stores and I've been trying to make them work
well. The Og test suite wasn't running for a while because it used multiple
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nitro-general