Design Patterns & Data::ObjectDriver

It's sad to see that the Class::DBI mailing list and wiki have closed down, for a number of reasons...

For one thing, I can feel for Tony--it's always hard to have a project that you're working on (out of your own time, for a job, or whatever) criticized, and to have customers--whether they're developers or end users--not happy with your decisions or the pace of your releases. That said, I don't know enough about the situation to say much more than it looks to have gotten out of control much more quickly than it should have.

But from another angle, the discussion about design patterns is really interesting to me (and, I gather, to a lot of people on the cdbi list).

It's a really fascinating problem, designing an extensible object-relational mapper (and a common one for people on CPAN). We've had a good, working mapper in Movable Type and TypePad since the first release of Movable Type (the venerable ObjectDriver code), which works with Berkeley DB, MySQL, PostgreSQL, SQLite, and a number of other databases that people have hacked it to work with.

Over the past couple of months, we've been revisiting our ObjectDriver code with the idea of keeping (mostly) the same calling structure, but adding layers for caching and database partitioning, and releasing the entire mess to CPAN as a module called Data::ObjectDriver. (Brad wrote about this, as well.)

The idea is to make application development simple; if that makes creation of new database-backed objects a little more difficult, then so be it. For example, with partitioning, we're not attempting to go the DB2 route of saying "anything can be partitioned in any which way, and we'll handle it all!"--frankly, while I honestly think that database partitioning is a feature any database platform should have, it's a hard problem, and is pretty application-specific. So what we're doing is preventing a mental model for doing partitioning: figure out what objects you want to use to partition your data on, and we'll do the mechanical work of automatically connecting to the right database and performing all operations there.

But the applicable part here is that we've talked a lot about getting the design pattern first for all of the drivers. In particular, we're converting TypePad to use the new Data::ObjectDriver, but we have a couple of extensions we want to make to it. We've talked through multiple inheritance, delegation, mixins, etc. Eventually we settled on using delegation, with a DBI-like system of a core Data::ObjectDriver::Driver::DBI class, which provides the main driver functionality, and Data::ObjectDriver::Driver::DBD subclasses for specific database platforms (MySQL, PostgreSQL, etc).

In addition, I've long thought that one of the main problems with Class::DBI is the fact that it's two things in one class: it's simultaneously the base class for all database-backed objects, and the class with all of the mechanical code to generate SQL statements.

Some of the design decisions that have always been in the ObjectDriver code--the separation of the core into a BaseObject and Drivers, which are 2 separate classes--will help to solve some of the Class::DBI problems. That's not to say that we won't replace those with other problems, of course. :)

Comments

[Matt S Trout]

If you fancy carrying on the design pattern discussions I'd invite you to visit http://dbix-class.shadowcatsystems.co.uk/ and drop by the dbix-class mailing list and IRC channel.

Some of the discussion on there already has been rather interesting, especially the hopes of a shared backend with Tangram based on Rosetta - this would support updateable views, truly portable SQL ASTs and much more, and might be worth providing an ObjectDriver backend for as well.