This is the issue that Pixie tries to address. Pixie doesn't mess with the internals of your object. It doesn't require you to implement your object in any particular way. It doesn't need you to write a schema describing your object. It doesn't need you to add a table for every class. It'll save pretty much anything. And if I can't save something, there are hooks so you can transform your object to and from something Pixie can save (and those hooks have reasonably distinctive names, so they shouldn't clash with your existing methods).
in reply to A Growing Dislike for SQL-OOP Mappers
Of course, there are drawbacks. You can't use SQL to find your objects for instance (less of a drawback than a deliberate choice, the plan was to add the capability to do more advanced searching later). And it currently sucks at concurrency (we do have a way forward on fixing that, but it's a matter of summoning up the enthusiasm/tuits). And if you've pulled a lot of objects from the store and mutate only a small proportion of them it'll be rather inefficient at writing things back to the database (this is the killer, for the life of us we can't think of a way of making this work in Perl 5; not without violating the principle of being catholic about what we'll store). And it could be better maintained. But it's worth a look.
The Perl 6 version will probably prod some serious buttock though.