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