Hi Colin: Well said! I think that the shortcomings in the schema are definitely part of the issue here.
For instance, the "biblio" table isn't really an accurate representation of a "Biblio" object, even/especially via DBIC. That's because a proper "Biblio" object is actually an amalgam of "biblio" and "biblioitems". Likewise, a proper "Biblio" object should also be shared with "deletedbiblio" and "deletedbiblioitems". There's also "biblioimages". I think that's what Robin was referring to when he talked about the need for having Koha:: objects. As Robin was saying, DBIC is an abstraction layer for the database. It is a much more convenient way of dealing with the database, but it seems to me that it's still all about CRUD. As Jonathan was saying, the purpose of having Koha:: objects is to add logical functionality. To make it a "Koha" object. That said, I think Colin and Kyle have good points about not wanting to abstract the abstraction, as it does add overhead. DBIC can be slow. Plus, the more layers, the more possible bugs. But unless I'm missing something... DBIC can't give us a single "Biblio" object that would contain data from "biblio" and "biblioitems" or "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object. Now... that's probably because of shortcomings with the schema, like Colin mentioned. But... it seems to me that we're stuck with the schema for the moment. Maybe "Biblio" isn't a good example, as it's a difficult one. Maybe something simpler... "reserves" and "old_reserves" wouldn't work. "issues" and "old_issues" wouldn't work. Unless maybe I'm missing how you create the ResultSet classes. That could be. (The "biblio" and "biblioitems" example would still probably be a problem though?) I don't know how this DBIC idea could work in many cases. Take subscriptions. There are several tables that deal with subscriptions. Or "messages". Wouldn't we want a "Koha" class that interacts with multiple tables via DBIC? Objects are cool, because you can store data and methods in them, but it seems to me that we should be thinking about our objects as "things" rather than tables. A "Biblio" touches several tables, or could be populated by several different tables. There are 4 "oai_set*" tables but we'd only want 1 "oai_set" object. Maybe I'm thinking about this too simplistically or too abstractly, as I don't have a code example at hand. I keep going back to this "Biblio" idea though (perhaps because biblio records are so key to Koha). It would have something like "save" and "delete" methods. The save method would add/update the "biblio" and "biblioitems" tables. The delete method would delete from "biblio" and "biblioitems" and write to "deletedbiblio" and "deletedbiblio" items. Likewise, there could be "image" methods for controlling the images associated with that bib. I suppose the downside of the image methods would be... you wouldn't necessarily want to load the whole biblio object just to get to the images, but I suppose you wouldn't have to. Koha::Biblio could be really lightweight. You could just give it a biblionumber, then do all sorts of functions related to that biblionumber without loading the marcxml or the biblio/biblioitems data. I'm looking at http://sourceforge.net/p/bizwerks/bizwerks/ci/master/tree/lib/BizWerks/Schem a/ResultSet/Department.pm but I don't see how the children() method works. It would be nice to have something like that with Biblio as well, so you can get the "children items". The attached orders. The attached reservations. All which would be their own "Koha" objects. I don't quite understand how the custom ResultSet methods would work. Maybe you could have custom ResultSet methods for Biblio that would get attached orders and attached reservations which might be DBIC objects. Yet... we also have "import_items". So I'd rather have a "Koha" object for "Item". But then if we're using "Koha" objects for "Item" and "Biblio", why would we not have "Koha" objects for "Reserves" and "Orders" which are more than just data. They have logic. Can this item be placed on reserve? I think that's similar to the "apply_security_policy" example given at http://search.cpan.org/~ribasushi/DBIx-Class-0.08270/lib/DBIx/Class/ResultSe t.pm. This seems to imply an application-level object using the DBIC object. Maybe it is silly if we just build simple wrappers around simple DBIC objects, but I think a fair bit of the code in Koha is more complex than just CRUD. I'm skeptical but I'm intrigued. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: [email protected] [mailto:koha-devel- > [email protected]] On Behalf Of Colin Campbell > Sent: Thursday, 11 September 2014 6:15 PM > To: [email protected] > Subject: Re: [Koha-devel] Koha and DBIC > > Its worth keeping in mind that DBIC is an Object Relational mapper and that > as such returns objects which are often better abstrations than those > currently embodied in Koha's module approach which tend to fiddle with the > representation of the entity not always very consistently. In a multitude of > cases a ResultSet of x objects and their inherent getters and setters is all we > need to construct the operations we need. In such cases wrapping the layer > in another one for purely formal reasons contributes little except for more > space to harbour bugs. > DBIC allows you to add extra methods to these objects and I'm sure in time > we'll identify plenty of these but we should be very thorough in reviewing > whether we need them, how we've implemented them and whether the > need is merely pointing up a shortcoming in the schema. > > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > [email protected] > skype: colin_campbell2 > > http://www.ptfs-europe.com > _______________________________________________ > Koha-devel mailing list > [email protected] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
