2014-09-12 3:31 GMT+02:00 David Cook <dcook@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.