[Catalyst] Re: Sharing a database handle between components

[Matt S Trout]

On Sat, Feb 09, 2008 at 07:55:17PM +0100, Aristotle Pagaltzis wrote:
> * Matt S Trout <dbix-class at trout.me.uk> [2008-02-09 19:15]:
> > What was wrong with just making the dbh acquired from -
> > 
> > Scalar::Defer::lazy { $app->model('Foo')->schema->storage->dbh }
> > 
> > ?
> 
> Actually, that fails: T::P::DBI::new calls `prepare_cached` on
> the DBH, causing the deferred scalar to cash in right away, thus
> defeating the lazification.

Hmm. T::P::DBI should probably be able to take a subref that provides
a dbh and use it on-demand. Or even one that provides an sth ...

> Another thing is that with my current solution, MyApp::View::TT
> does not refer to a specific model itself; it is the MyApp class
> that wires the DBH from a specific model into the view that needs
> the DBH. This coupling is IMO more correct than coupling the view
> class to a particular model class.

In this context, MyApp is acting as an IOC service.

To reduce coupling I'd probably do (in MyAPP)

__PACKAGE__->config(
  'View::TT' => { template_db_model => 'Foo' }
);

and then have the view use thatas the arg to $c->model during new.
 
> So it seems to me that the clean way to do this is definitely to
> do some additional setup after Catalyst has finished setting
> itself up.

Disagree - see above.
 
> The question is, will running code in the top-level scope of
> MyApp after `__PACKAGE__->setup` paint me into a singleton-ish
> corner or not? And will it continue working for the foreseeable
> future?

Yes, but should be easily convertable to instance-based later.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/