Chris, I tent to agree with you, but a Koha::Object makes sense to me. For instance, bug 12891 [1] shows us that we need an object to refactor common stuffs.
[1] http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31515 2014-09-17 9:50 GMT+02:00 Chris Cormack <chr...@catalyst.net.nz>: > * Jonathan Druart (jonathan.dru...@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.h...@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.r...@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@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@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@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 _______________________________________________ Koha-devel mailing list Koha-devel@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/