On Jan 3, 2008 10:41 AM, Justin Ellison <[EMAIL PROTECTED]> wrote:
> Thanks for the reply John - see inline:
>> but then override the schema in the inventory class:
>>> package My::Inventory;
>>> use base qw(Rose::DB::Object);
>>> __PACKAGE__->meta->setup(
>>>     table       => 'inventory',
>>>     ...
>>>     primary_key_columns  => [ qw(sku_code) ],
>>>     schema => 'b_custom',
>>> );
>> That should do it.
> Indeed it did.  Thanks for that.  I sent you a stripped down test case -
> my My::DB looks more like this:
> Domain  Type            Schema
> pts             main            b_main
> pts             custom  b_custom
> prod            main            prod_main
> prod            custom  prod_custom
> Because my schema name can change based upon domain and type (and I want
> to keep everything in My::DB), I did the following in my Inventory
> class:
>     schema => My::DB->new_or_cached(type => 'custom')->schema,
> It works, and seems to be okay - see any problems with that?

That should be fine, so long as the default domain is set
appropriately before that line of code is run.

> I got the '$DB ||= My::DB->new;' snippet from somewhere - maybe the mailing
> list?  Anyways, it improved execution time on my test script by cutting it in
> half.  Plugging in new_or_cached into my DefaultObject class works the same,
> and looks cleaner, so I'll stick with it - but is there any difference here or
> is it just semantics?

The new_or_cached() method, when using the default caching code and
classes, does some interesting db handle preparation and cleanup when
running under mod_perl.  Here's the documentation chain:


You can customize these behaviors by creating your own custom db_cache_class:


Either way, my warning about the $DB ||= stuff in your test case code
was mostly that you had it appearing in each class, rather than just
once in the common base class.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Rose-db-object mailing list

Reply via email to