[Koha-devel] [RFC: DBIx::Class 0/3] use DBIx::Class ORM for database access

Andrew Moore andrew.moore at liblime.com
Fri Oct 24 16:10:41 CEST 2008


Ryan mentioned recently that I'v been exploring using DBIx::Class to help
us abstract away many of our database interactions. Although I don't
believe I have a workable solution yet, I think I've been making progress.
I'd like to share what I have so far to see if you guys have any opinions
on how this might work, or even some help on solving some of the remaining
questions and problems. There are a few patches in emails that follow this
one that implement a partial solution.

DBix::Class is one of the more popular object-relational mapping (ORM) tools
for perl. It can help us by abstracting away our database interaction and letting
us use a few objects to talk to the database instead.

The following patches show one way that we could start using DBIx::Class, but 
are certainly not the only way. I hope that this can help us out, but I'm
looking forward to hearing about other tools that we could use or other ways
to use DBIx::Class.

Some of the advantages of this proposal are:

We would no longer have to write (as much) SQL. As perl programmers, we're pretty good
at perl, but typically our SQL skills aren't as refined. This lets us outsource the SQL
to the guys that write the DBIx::Class modules. These modules are well tested and
dependable.

This is a step towards supporting other databases. Since we can abstract away the
SQL, we won't be writing MySQL specific SQL. I think this is a step towards supporting
postgresql or Oracle or other databases. DBIx::Class can run on many popular databases.

Some downsides:

I think the worst problem here is that there is probably a large startup time being paid
here. The Schema::Loader reads the whole database schema and makes a perl object out
of it. That's probably more computing than we want to do with each page load. Since
we're not running under mod_perl in most instances, this is probably a deal killer.
I'm not sure if it's best to solve this by moving to mod_perl, letting the Schema::Loader
use it's dump_to_directory method to make a cache of the database structure, explicitly
define the database structure to DBIx::Class, or what. I do think this is the most
important problem that needs to be solved before starting to use this code.

There are reports that DBIx:Class may come with a performace penalty. We can research
this more throoughly and see how bad it's expected to be. We can also write direct SQL
in those places where performance seems to be a real problem.

DBIx::Class is a new dependency, and it requires some modules itself.

Finally, thanks to Marc Chantreux and others on the koha-devel list for encouraging
me to make forward progress on this.  I was hoping that I was not the only one
looking for something like this.

Andrew Moore (4):
  DBIx::Class - adjusting t/Makefile to find private library
  DBIx::Class - new C4::Schema object
  DBix::Class - moving C4::ClassSource over to using DBIx::Class
  DBIx::Class - Changes to C4::Members to start using DBIx::Class

 C4/Accounts.pm                            |    2 +-
 C4/ClassSource.pm                         |   66 ++++++++++++----------------
 C4/Members.pm                             |   25 +++++------
 C4/Schema.pm                              |   20 +++++++++
 t/Makefile                                |    2 +-
 t/lib/KohaTest/ClassSource.pm             |   34 +++++++++++++++
 t/lib/KohaTest/ClassSource/ClassSource.pm |   56 ++++++++++++++++++++++++
 7 files changed, 151 insertions(+), 54 deletions(-)
 create mode 100644 C4/Schema.pm
 create mode 100644 t/lib/KohaTest/ClassSource.pm
 create mode 100644 t/lib/KohaTest/ClassSource/ClassSource.pm




More information about the Koha-devel mailing list