[Koha-devel] Koha and DBIC

[Kyle Hall]

On Thu, Sep 11, 2014 at 3:31 AM, Jonathan Druart <
jonathan.druart at biblibre.com> wrote:

> 2014-09-11 2:39 GMT+02:00 Kyle Hall <kyle.m.hall at gmail.com>:
> > On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart
> > <jonathan.druart at biblibre.com> wrote:
> >>
> >> Hi all,
> >>
> >> IMO a ResultSet should not be instantiate in a pl script for some
> >> reasons (I already listed yesterday, nothing new :))
> >> - should be unit tested
> >> - easier to maintain
> >> - easier to reuse
> >>
> >> But I don't think it's a big deal.
> >
> >
> > I agree with all these principles, and none of them conflict with what I
> am
> > proposing. Result and ResultSet methods are no different than C4/Koha
> > methods and subroutines.
>
> Yes they are, as Robin said, It is an API for the DB, not for the
> functional job.
>

Again, only if we treat it that way. We can leverage DBIC to add formality
and commonality to our OO code where it's always been bespoke
implementations previously.


>
> >> Please comment this part of code and share yours!
> >
> > 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.


>
> > 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.

We are a collective of developers with many different styles and opinions.
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.

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140911/eed21443/attachment.html>