* Jonathan Druart ([email protected]) 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 <[email protected]>: > > 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 <[email protected]> > > 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 > >> [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/ > _______________________________________________ > 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/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
signature.asc
Description: Digital signature
_______________________________________________ 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/
