To expand on the comments I made to you on the mailing list:

OO databases have been around for over a decade but the technology is still rather moribund. As for our company, such a database would be a perfect fit for our data needs but there's no way in heck we would use one. Object Query Language was never standardized (well, it was, but vendors ignored it) and frankly, we have been in the position where we have to switch backends so having a standard query language is critical.

As for Class::DBI and DBIx::RecordSet, I don't think there's much of a choice there for me. For a pre-existing application, many people already have a well-defined object system in place and a natural migration to Class::DBI or something similar is a straightforward refactor as opposed to a redesign. I know which I would prefer.

DBIx::RecordSet, by contrast, uses a procedural interface, encourages the use of typeglobs and has no test suite (its "test.pl" does not count.) There's no way I'm going to tell my boss that we should base our fortunes on that. That's not to say it isn't a good piece of software. Maybe DBIx::RecordSet would be a nice tool to experiment with on a new, small app that's not mission critical, but that's all I would use it on. Give me a solid test suite that plays well with Test::Harness and I'll reconsider.

Class::DBI, by contrast, has a huge test suite, it's dead simple to use and for large applications slinging objects everywhere, it can frequently be used internally to make the code much easier to manage without the programmers working in the upper layers even noticing a difference. Is it perfect? Heck no, but for those applications where it fits, it fits quite nicely.

If you just hate Class::DBI, check out Tangram, Alzabo or some other well-tested software.