[Catalyst] Transactions with mysql - can't locate db_Main
blblack at gmail.com
Thu Jan 19 07:29:03 CET 2006
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).
*::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
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
More information about the Catalyst