[Koha-devel] Koha and DBIC

[David Cook]

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: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Colin Campbell
> Sent: Thursday, 11 September 2014 6:15 PM
> To: koha-devel at lists.koha-community.org
> 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)
> colin.campbell at ptfs-europe.com
> skype: colin_campbell2
> 
> http://www.ptfs-europe.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> 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/