[Koha-devel] Koha and DBIC

[Kyle Hall]

On Fri, Sep 12, 2014 at 3:43 AM, Jonathan Druart <
jonathan.druart at biblibre.com> wrote:

> 2014-09-12 3:31 GMT+02:00 David Cook <dcook at prosentient.com.au>:
> > That said, I think Colin and Kyle have good points about not wanting to
> > abstract the abstraction, as it does add overhead. DBIC can be slow.
> Plus,
> > the more layers, the more possible bugs.
>
> We need to create a Koha API, a good and better API. For that the only
> way to do is to add Koha classes to wrap the DBIC ResultSet classes
> (note that we could extend it).
>

This ^. That's the solution. If we extend the resultset class then we can
retain all the DBIC methods and retain the ability to leverage all the
strengths of DBIC. For example, let's say we want to carp/die if a
particular key isn't passed to create(), or maybe we any delete to fail if
there's still a row in table X that's related to it. All we need to do is
use inheritance so we can test our conditions, then call the parent's
create(), or delete() or whatever method.



> I really don't think performance will be impacted here. The difference
> can be ignore.
> I disagree with the "more layers, more bugs" idea. An abstraction
> layer adds flexibility and a better overview.
> For instance, I think we should have a Koha::Record class. Biblio and
> Authority would be a Koha::Record.
>

We can use multiple inheritance or Roles ( interfaces in OO terminology )
to achieve this. That way each Biblio and Authority share a common set of
methods and can be used interchangeably in certain circumstances.


> Do you think this new class adds more complexity? To me it adds
> consistence and the common code will be refactored in this class.

> But unless I'm missing something... DBIC can't give us a single "Biblio"
> > object that would contain data from "biblio" and "biblioitems" or
> > "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object.
> > Now... that's probably because of shortcomings with the schema, like
> Colin
> > mentioned. But... it seems to me that we're stuck with the schema for the
> > moment. Maybe "Biblio" isn't a good example, as it's a difficult one.
> Maybe
> > something simpler...
>

DBIC can't give us a single record object technically, because of our
schema ( the tables should be merged into one at this point in time ).
However, we can solve this in two ways. We can either just write
$biblio->biblioitem->marcxml and say it's not a big deal, or we can just
add methods for each of the biblioitem methods so we can just treat them as
one object:

sub marcxml {
    my $self = (@_);
    return $self->biblioitem->marcxml;
}

We can have a method that returns a MARC::Record, or perhaps we could even
have our Result::Biblio inherit from MARC::Record, and our
ResultSet::Biblio inherit from MARC::Batch.

Koha has a lot of complex concepts. Because it offers a lot of modules
> and possibilities to the users. Koha has to work for every
> configuration across the world.
> Biblio won't be a special case. So there are not reason to cut the
> class in 2 groups: the simple and the complex.
> All lot will need their own modules, because we need to be flexible and
> logical.


I absolutely agree. I think at the simplest we can use our Result and
ResultSet classes, at the next level we can extend our Result and ResultSet
classes, and at the far end of the spectrum we have fancy classes that
don't map easily to the database but use DBIC objects to get things done.


>
> > I'm skeptical but I'm intrigued.
>
> Thanks to share your interest :)
> You managed to tell what I didn't.
>

Agreed!

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