[Catalyst] DBIC::Schema [and schema::loader] from YAML

[leonard.a.jaffe at jpmchase.com]

[ I tried to make the attributions clear via some liberal editing...laj] 

> > > > Jon Warbrick started it all by asking: 
> > > > [ how do I configure DBIC::Schema models via YAML? ] 

> > > Brian Cassidy replied: 
> > > [ yaml example edited - for brevity ]

> > Len Jaffe then asked: 
> > How do I make sure that my SchemaLoader can see the config when it 
tries to execute 
> > __PACKAGE__->connection? 
 
> To which "Brandon Black"  Replied:
> As with all things Perl, TIMTOWTDI.  While you *can* specify the 
connection in the Schema, 
> its generally not a great idea.
> 
> Best practice would be that myapp::SchemaLoader::foo should just contain 
the "loader_options" 
> method, and really nothing else (no connect/connection call).  Then when 
the Model makes the 
> connection using your connect_info configuration, that's when the actual 
dynamic loading will 
> happen. 

I dug back into the source code and discovered this shortly after sending 
my question. 
What I then discovered is threaded DBI problems, which I believe can be 
alleviated by 
installing DBI from CPAN rather than PPM. Which puts a few more yaks into 
my shave queue
as I need to reset my development install of perl before I'll upgrade 
anything on my prod box.

That being said - at least I now know how to get that info up into the 
YAML file.


> Even better practice would be to use the helper in create=static mode 
instead of create=dynamic, 
> so that you're not re-scanning the table definitions at every server 
start.  If you insist on 
> maintaining your database the old-fashioned way (or have no control over 
it), you can regenerate 
> via create=static each time there's a change in the DDL, and diff versus 
the previous version to 
> see the changes, etc. 

Hmm. Interesting.  I'll try this on my dev system. After I reset it.
$yaks->push('create=static');


> The next step beyond that is to start maintaining your database tables 
using the generated 
> DBIC schema and the SQLT/->deploy support.  Then you won't need Loader 
at all.

$future_yaks->push(SQLT/deploy);

 
> Another good practice is to move the Schema definitions outside of the 
myapp:: Catalyst-app 
> namespace, so that you can deploy the Schema independently for other 
tools that might need 
> access to your database. 

Then what? 

      package myapp::Schema::foo;
      use base qq/some::other::namespace::Schema::foo/;

Flashing back to CDBI...seems reasonable...might do this if i end up 
porting from mysql to db2.


Thanks for all of the advice.

Len.
$c->model('len::yaks')->find('shears');


-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060928/e03d7c91/attachment-0001.htm