[Koha-devel] Koha and DBIC

[Jonathan Druart]

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 at catalyst.net.nz>:
> * 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