According to the forwarded message below, Class::DBI::Loader is unmaintained. Since you guys are probably the heaviest users of it, I thought you might want to consider talking to Sebastian about taking over maintenance of it.
- Perrin
--- Begin Message ---On Thu, Jan 19, 2006 at 12:29:03AM -0600, Brandon Black wrote: > On 1/18/06, Perrin Harkins <[EMAIL PROTECTED]> 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/ + _______________________________________________ Catalyst mailing list [EMAIL PROTECTED] http://lists.rawmode.org/mailman/listinfo/catalyst
--- End Message ---
