That's a lot of work, and it seems to me that the cost/benefit ratio is hard to justify. I'd say just pick an RDBMS-OO mapper you like (or even none at all, and use straight DBI) and then stick with it. If you really need to tear it out later and replace it, then you can create the required adapter layer in order to maintain your API. But if you never have to do that, then you just saved yourself a lot of work.

Quite a bit of work. But that's a matter of perspective depending on the situation. If I'm stuck with say for example Class::DBI, I still have to create a layer to seperate it's is-a junk from my top-level module. If I'm already doing the work to do that, the rest is easy.

As you point out, Rose::DB::Object is a little more polite about things. In the big scheme of things, I'd never need multiple SQL->OOP mappers. My frustration with isa-a and Class::DBI/DBIx::Class has turned into hacking/learning session on using multiple layers or abstracting out the is-a problems. Add 3 parts of Because I Can to that recipe. :-)