[Catalyst] Transactions with mysql - can't locate db_Main

[Matt S Trout]

On Thu, Jan 19, 2006 at 12:29:03AM -0600, Brandon Black wrote:
> On 1/18/06, Perrin Harkins <perrin at elem.com> wrote:
> > On Thu, 2006-01-19 at 04:09 +0000, Matt S Trout wrote:
> > > > I believe it's because Class::DBI::Loader (which Catalyst::Model::CDBI
> > > > uses) calls set_db in each subclass rather than in the base class.
> > >
> > > Ick. The (actively maintained) DBIx::Class::Loader does this properly.
> >
> > Are you saying that Sebastian doesn't maintain Class::DBI::Loader
> > anymore?  If so, maybe a call for a volunteer to take it over would be
> > in order.  (I am not volunteering, since I don't use the module.)
> >
> 
> I don't think he is (actively anyways).

No, he definitely isn't; certain events rather killed his motivation to
give a flying fsck about Class::DBI.

> *::Loader is great for very simple databases/apps, or to get up and
> running against an existing database quickly, but it seems anyone
> working on a sufficiently complex project will end up running into the
> limitations and moving off of it.  Loaders make assumptions about the
> nature of your relationships and what they should be named, and their
> OO-specific attributes - all of which one could do a better job of
> manually for any given database.
> 
> For me the main reason to use it at all was to cut down on
> duplication, since I already other definitions of my schema in my own
> format that are used in creating and maintaining the database itself,
> and I didn't want to have to make schema changes in two places all the
> time.

I long since started using a common format that generates both my CREATE TABLE
staments and my class definitions. 

> I saw some irc traffic recently about DBIx::Class getting
> SQL::Transform support, which is great news, and yet another reason
> not to use Loader.  Define your tables in DBIx::Class, and generate
> your "CREATE TABLE" stuff from there, instead of creating/managing
> your database with external tools and then Loader-ing it into
> DBIx::Class.  With the extended relationship attributes and
> column_info and all that, DBIx::Class is capable of knowing more about
> your tables than SQL does, so it makes sense to make it the
> authoritative source.

SQL::Translator::Parser::DBIx::Class is already in trunk; needs some work
to figure out the right FOREIGN KEY constraints to apply for everything but
it's a damn fine start (many thanks to Jess Robinson for this).

I'll look at providing a nice schema declaration syntax once we get 0.05 out
the door.

-- 
     Matt S Trout       Offering custom development, consultancy and support
  Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +