On Thu, Nov 6, 2008 at 6:32 PM, Rick Welykochy <[EMAIL PROTECTED]> wrote: > It seems that DBIx::Class grew out of Class::DBI and might be more > sophisticated for our purposes. > > There is a perl monks comparison of these two here: > > http://www.perlmonks.org/?node_id=700283 > > with some pros and cons for each.
Hi Rick - Thanks for looking into this stuff. I've also worked with Class::DBI in the past and and thought it worked rather well. I chose to explore DBIx::Class for a few advantages it seems to offer over Class::DBI. Some of them are detailed well in that perlmonks article you pointed out. A few really hit home for me. Namely: * DBIx::Class is being actively maintained. Class::DBI last had a release about 2 years ago, and from what I can tell no more releases are planned. * DBIx::Class supports JOINs between database tables. * DBIx::Class supports "inflating" or instantiating certain data fields into objects. So for example if you have a datetime field in your database, it can return you a DateTime object for that field, or it can return a Business::ISBN object for all ISBN fields. Your point about the accessor and mutator methods being simpler on Class::DBI is a valid one. The accessors and mutator methods on DBIx::Class methods are a bit longer than the ones with Class::DBI. Not having a single method that performs access and update, though, may have actually been a conscious decision of the authors of DBIx::Class.. It's one of the common practices that is actually argued against in Perl Best Practices and is often undesired. If we'd like to explore improving our accessors and mutators on some of our objects, I hope we can do that when or if we start moving our packages like C4::Items, C4::Members, and the rest into classes themselves. I'm hopeful that adding an ORM layer like this will make it easier to promote those packages to classes soon. Thanks again for looking over this code. I'm interested in hearing more from you since I think it's important we get this right. It would be foolish for me to think that my first proposal would necessarily be the "best" one. -Andy _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
