[Koha-devel] Koha and DBIC

[Kyle Hall]

>
> First question to be asked: why are we adopting an ORM?
>
> If we are using it to abstract the DB engine selection (i.e. making Koha
> usable with Postgres instead of only MySQL) I'm sure we are wasting our
> time.
> What's the point of rewriting the whole thing to just move away from an
> enterprise grade DB engine to another? Is it worth the trouble? I'm glad
> that using an ORM also serves that purpose, but...
>
>
In the past if not now, there has been concerns about the future of MySQL.
I think there has been a strong interest in enabling Koha to use Postgres
at the very least.


> I think our project is complex enough to benefit from strictly sticking to
> design patterns, such as the repository pattern; in which the ORM takes
> care of persistence and nothing more, and we build our business logic on
> top of that. On that subject, I fully agree with Robin, that we shouldn't
> rely on hooking the ORM to solve any business logic issue: we need to have
> our own abstraction layer with a proper API we maintain and unit test
> (mocked tests, and let integration tests deal with the ORM interaction).
> Hooking the ORM mixes layers, businesses and problems. That's why it is so
> hard to write some tests for Koha.
>

I can totally agree with this, except I don't see where we are using any
design patterns with Koha. I we need to retain the pattern of Objects and
Object Sets. But we already have those though DBIC! In the end we could
easily yank out DBIC and replace it with something else so long as it
provides the same methods ( create, update, delete, find, search, etc ).

I am troubled by the idea that we should wrap all our dbic classes in yet
more classes. Every example I've seen of this has more code by a factor of
almost 10. I don't know if Koha is so complex that it requires a repository
pattern.

Look at this example:
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31607&action=diff#a/Koha/Schema/ResultSet/Reserve.pm_sec1

How much more difficult will this be for developers, and how much more
overhead will it require if we wrap our objects in more objects? We'd have
to fetch the Row objects, wrap them in KohaRow objects, wrap those in a
KohaRowSet, and return them. Certainly, but far more complicated.

That being said, if the majority agree, than I will be the first to jump
aboard. However, there have definitely been others who are reticent  as
well.


>
> Also, our ERD needs some tweaking, to aid maintenance, code simplicity and
> to support an OO design [1]. For instance, a biblio should definitely have
> its table, and if biblioitems breaks the design, then we should just merge
> those tables. I wouldn't implement any hack on the code to preserve that
> discussed structure. I'd rather spend the time fixing it.
>

I totally agree. The biblio and biblioitems tables need to be merged.
Finding a volunteer will be the hard part!


>
> So at that level, we should implement the repository pattern, with the
> following goals:
> - Consistent API, independent of the DB model (people use our API, no need
> to know how we built our DB structure).
>

Is this so other software can make use of Koha's functions and methods?


> - Separation of concerns between layers (easier to code, easier to test,
> etc)
>

I will concede that unit testing would be much easier if we could
instantiate objects and object sets without using the database. It *is*
trivial to create Result objects without touching the db, but ResultSets
are another matter. However, it seems like it may be possible:
http://modernperlbooks.com/mt/2011/05/testing-dbix-models-without-the-database.html


> - Let the ORM take care of DB stuff and use the spare time to talk about
> cats and food. [2]
>

Don't forget about dogs! We've got plenty of dog lovers in out community ; )


>
> I'd also like to have a RESTful layer for that API, that should be
> straightforward to maintain: endpoint routing, authorization layer, call to
> the right method, output. It is outside the scope of this thread, but a
> better separation of concerns might make it easier to achieve in a short
> term. We could the gradually move away from our .pl mess, that contains
> lots of business logic that doesn't get tested.
>

This I completely agree with. I think all outside systems should interact
with Koha though a well designed restful interface. I'm hoping to get
started on this soon. Jesse Weaver has already written some great code I
can use as a start.

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