[Koha-devel] [RFC ver2 4/4] DBIx::Class - Changes to C4::Members to start using DBIx::Class

Ryan Higgins ryan.higgins at liblime.com
Wed Nov 12 05:04:35 CET 2008


I finally found the time to play around with this over the past few days,
and I very much hope that others make the time to do so.

The first module that I tried to look at was Serials.pm, since I did some
work
on it relatively recently.  What I found immediately is that none of the
relations
were auto-discovered by the schema generator.
I am guessing that this reveals a lack of fk defs in our base schema in this
module.
While this may seem like a real pain, and seem to raise the bar, so to
speak, in terms
of the amount of effort required to adopt an ORM, I think that investing the
time now
in firming up and fixing Koha's base schema will be well worth it in the
long term.
One of the things I really like about what I've seen in DBIx::Class is that
once you
define the relationships properly in your schema object, getting at the data
you want
becomes pretty easy.  Joins are handled for you by the abstraction layer
itself.
This will only work if some of the shortcomings of Koha's core schema are
addressed, however.
If they aren't, then we'll end up passing all sorts of modifiers to our
Schema objects in
order to compensate, in which case we may as well just be writing SQL.

So my feeling is that the power and advantage of DBIx::Class can only be
taken
advantage of if some of our problematic db schema issues are addressed as a
part
of this work.  Once this is addressed, I think this will really clean up
core Koha modules,
and allow the RDBMS to take care of the things that it's good at taking care
of, and give
us code simplification and multi-db support at once.

In short, I'm highly in favor of pursuing this, with the caveat that we have
a bit of
cleanup to do in the process.  An interesting line of thought is whether one
might
approach this 'cleanup' (i.e. properly defining pks, fks & table relations)
from the POV
of the db schema itself, or from the POV of the db abstraction layer.
Obviously, it's harder
to do it from the abstraction layer for an extant schema, but it can be
approached from
either direction.

I hope that others get a chance to apply these patches and offer some
feedback.
I'd like to see this implemented.

Regards,
Ryan


On Sat, Nov 1, 2008 at 3:53 AM, Henri-Damien LAURENT
<laurenthdl at alinto.com>wrote:

> Hi andrew.
> Thanks for your hard work.
> I will try and test this.
> I hope that Marc will have some time to this too.
> let's stay tuned.
> --
> Henri-Damien LAURENT
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>



-- 
Ryan Higgins

LibLime  *  Open-Source Solutions for Libraries
Featuring KohaZOOM ILS
888-564-2457  x704
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20081111/8702aaf0/attachment-0002.htm>


More information about the Koha-devel mailing list