[Koha-devel] Koha and DBIC

[Chris Cormack]

* Jonathan Druart (jonathan.druart at biblibre.com) wrote:
> \o/
> If I understood correctly, it's exactly what I had in mind, so I totally agree!
> 
> 2014-09-16 13:16 GMT+02:00 Kyle Hall <kyle.m.hall at gmail.com>:
> > Yes. I'm imagining something along the lines of Koha::Object, and
> > Koha::Object::Set which would have all the boilerplate we need for general
> > use ( get, set, find, search, etc ). Then all our table-tied objects would
> > inherit from Koha::Object and a set of those objects would inherit from
> > Koha::Object::Set. Both of those classes can be DBIC-aware internally.
> >
> > Internally Koha::Object would have a DBIC Result as a property, which can be
> > used independently from the database ( which would be good for unit testing
> > ). Each Koha::Object::Set would normally keep only a ResultSet internally
> > and work on that until asked to return a Koha::Object, at which point it
> > would wrap each Result in a Koha::Object and store them internally, or
> > return an array of them depending on what type of return value the method
> > was called with.
> >
> > I would be willing to write up Koha::Object and Koha::Object::Set if this is
> > what Robin, Tomas et. al. are looking for.
> >
> > In this way we have DBIC totally encapsulated so the code using Koha::Object
> > and Koha::Object::Set's is totally DBIC unaware but internally is DBIC
> > aware.
> >
> > In addition, if we have these two classes to inherit from, it will reduce
> > the amount of code we must write, and make it much easier for new
> > developers. One we have Object and Object::Set written, we don't have to
> > rewrite our CRUD boilerplate for each and every new class we add.
> >
> > What do you think?
> >
> > Kyle
> >

I cant answer for Tomas or Robin, but this is not what I was thinking at all.
We don't need more boilerplate setters and getters, DBIX::Class does this for us.

What we don't want, is DBIx::Class or for that matter Koha::Object calls in the .pl files

I dont think we need to build an abstraction over DBIx::Class, certainly thats 
not what Robin was asking. What we don't want to see is DBIx::Class calls in the .pl files
they should live in modules (objects) in the Koha:: namespace.

In fact all of our pl files that are longer than about 40 lines should all be 
rewritten, all the business logic should be in the modules.

I think there may be a misunderstanding, we dont need to abstract database
access over top of DBIx::Class .. thats what it's for. What we dont want to be doing
is setting and getting from inside the pl files.

I think if you look at the Koha::Biblio modules etc that Robin has written
they illustrate this.

Hopefully this is clear, to restate

-1 for DBIx::Class calls in the .pl
-1 for Koha::Object and Koha::Object::Set
+1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc

Chris



> > http://www.kylehall.info
> > ByWater Solutions ( http://bywatersolutions.com )
> > Meadville Public Library ( http://www.meadvillelibrary.org )
> > Crawford County Federated Library System ( http://www.ccfls.org )
> > Mill Run Technology Solutions ( http://millruntech.com )
> >
> > On Mon, Sep 15, 2014 at 3:11 PM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>
> > wrote:
> >>
> >> > I am troubled by the idea that we should wrap all our dbic classes in
> >> > yet more classes. Every example I've seen of this has more code by a factor
> >> > of almost 10. I don't know if Koha is so complex that it requires a
> >> > repository pattern.
> >> I think that it would require rewriting Koha. This changeover might just
> >> be too complex for us.
> >>
> >> > How much more difficult will this be for developers, and how much more
> >> > overhead will it require if we wrap our objects in more objects? We'd have
> >> > to fetch the Row objects, wrap them in KohaRow objects, wrap those in a
> >> > KohaRowSet, and return them. Certainly, but far more complicated.
> >> I would say: Leave all storage related actions in Koha::Schema. KohaRow
> >> does not make sense to me.
> >> Furthermore, define the objects that actually have 'real' business logic
> >> and put that in some Koha::Object.
> >>
> >> Marcel
> >>
> >> _______________________________________________
> >> 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/
> >
> >
> >
> > _______________________________________________
> > 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/
> _______________________________________________
> 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/

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/018921ed/attachment-0001.pgp>