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 <chrisc@catalyst.net.nz>:
* Jonathan Druart (jonathan.druart@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@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@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