[Koha-devel] Koha and DBIC

[Jonathan Druart]

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

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'm skeptical but I'm intrigued.

Thanks to share your interest :)
You managed to tell what I didn't.