[Koha-devel] Koha and DBIC

Jonathan Druart jonathan.druart at biblibre.com
Thu Sep 11 14:09:33 CEST 2014


2014-09-11 13:29 GMT+02:00 Kyle Hall <kyle.m.hall at gmail.com>:
>> > Can you see how this gives no advantage, but simply wraps the useful
>> > code in
>> > another layer of abstraction? There simply is no advantage to doing
>> > this. In
>> > the long run this type of thinking will make things more complicated and
>> > more error prone than they need to be.
>>
>> The advantage is to share responsabilities, which is already a lot.
>
>
> I don't understand your comment.

Not important, I just repeated myself: the functional job should not
be done under the Koha::Schema::Result. It should only contain DB
relationships without any intelligence on what happen above.

>> > Instead of all this code we simply need to add one method to
>> > Result::Borrower. Here is the gist of it:
>> >
>> > sub is_debarred {
>> >     my ( $self ) = @_;
>> >     return $self->debarred_date() > dt_from_string();
>> > }
>> >
>> > Think about all the overhead and complexity that is removed by this
>> > variation.
>>
>> I don't understand where is the complexity. We need Koha::Module
>> packages. We cannot put all our code into
>> Koha::Schema::Result::Module.
>> Why everyone is afraid of abstraction layers?
>
>
> We *don't* need Koha::Module packages for everything! My point is that DBIC
> provides us with an abstraction layer already! Wrapping a DBIC class in
> another class provides no advantage and just obfuscates our code, increases
> hardware requirements, and leaves more room to introduce bugs. If we are
> just going to use DBIC  to avoid writing direct sql queries, we should be
> using something like Fey instead.

Give me examples please: Which "modules" don't need specific packages?
IMO, these ones should have their own modules: Order, Supplier,
Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget,
Fund, Patron.

> We are a collective of developers with many different styles and opinions.

I completely agree with that :)
That fact is that DBIC has been pushed into Koha 1 year ago and we
don't have any plan. I tried several times and my patches have just
been rejected.
We never had this discussion (I mean a real/constructive discussion),
nobody gives examples.
I really would like someone shows me what he has in mind, like I did
for Koha::Acquisition::[Order|Bookseller].

> We often have very different approaches to how we implement new features. If
> we go down this path of wrapping DBIC in another abstraction layer, we
> simply continue down this patch of having many different bespoke
> implementations. If we use dbic as our abstraction layer, we remove much of
> that issue.

I we reach an agreement, we can do what we want.

I hope some of you will be in Cordoba in 3 weeks! :)


More information about the Koha-devel mailing list