First off, a note to Galen. I reported to you that I had experience with DBIx::Class. Make that Class::DBI instead. I am reading up on DBIx::Class now. 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. What I like about Class::DBI is that it created a data model object for each table, i.e. something like Ourspace::Itemtype for the itemtype table. Instances of that object are loaded and initialised from the database. In the examples I have been reading kindly posted by Andrew Moore I am seeing field (attribute) accesses like the following using DBIx::Class ... $row->get_column('cn_source') This is not much different than the following: $hash->{cn_source} IMHO. Part of the advantage in an OR mapper is having first class data model objects, i.e. the above would become: $obj->cn_source and changing the value of the cn_source attribute is accomplished quite simply by $obj->cn_source('new_value') There might be some concern of the extra overhead involved in creating data objects for each database fetch. cheers rick -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor When the power of love overcomes the love of power, the world will know peace. -- Jimi Hendrix
On Thu, Nov 6, 2008 at 6:32 PM, Rick Welykochy <rick@praxis.com.au> 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
Andrew Moore wrote:
* 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.
Agreed. From what I have read, DBIx::Class seems to be the go. I am certainly interested in pursuing the option of the package creating a data model object, i.e. Business::ISBN, that contains all attributes (columns) of a row from the table. As well, the power of doing joins automatically cannot be underestimated. Finally, if "inflating" implies that you can quickly load data from without populating every attribute unless you really want to is very useful. In Class::DBI one could specify which columns are required on the initial load (for speed) and which are to be loaded later if eventually required.
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.
When time permits I would like to get into the code you've written as review how cleanly it can be written. I often think of things in the clean style of Python these days. If the Perl code can "look nice" and DWIM, then we are on the right track. If the solution we come up with is clunky and difficult to use, then I think we've failed. I good starting point is to write a tutorial for what you want to accomplish. Here is a really simple and contrived example that probably doesn't exactly match up with what DBIx::Class can do (yet), but should get the point across: ---------------------------------------------------------------------- # load and manipulate item types in Koha 3 use C4::Datad:ItemType; # encapsulation of all things regarding item types # select my $bookitemtype = C4::Data::ItemType->select('BK'); # select one by primary key my $allitemtypes = C4::Data::ItemType->select_all; # ref to array of objects print "Book Item Type: ", $bookitemtype->description, "\n"; print "All Item Types:\n"; printf "%2s %s\n", $_->itemtype, $_->description for @$allitemtypes; # update $bookitemtype->description('Libres'); $bookitemtype->_commit; # insert C4::Data::ItemType->insert({itemtype->'N1',description=>'new item type' ... etc}); # delete C4::Data::ItemType->delete('N1'); BTW: what is the C4 namesapce? why is it called C4? cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor When the power of love overcomes the love of power, the world will know peace. -- Jimi Hendrix
Yeah there are a bunch of reasons, its C4 because that was the original working name of the project, the old system we were replacing was C2, and C4 was twice as good, but might explode. (Theres no point working if you cant have fun doing it) Next it became Kumara .... then finally Koha. Someone could change the namespace if they wanted, its a bunch of work for a purely cosmetic thing, so no one has bothered yet :) Chris On Sat, Nov 8, 2008 at 9:22 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
BTW: what is the C4 namesapce? why is it called C4?
It's Koha's perl module directory/namespace. Chris Cormack told me the reason, once, I think, but basically it's C4 de facto, because it is.
I like the joke that it's C4 because it explodes.
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (4)
-
Andrew Moore -
Chris Cormack -
Joe Atzberger -
Rick Welykochy