I love SQLite, and so does most of the world.
It is successful and liked for many of the same reasons that the
Tons of features (like concurrency, access control, sequences, and so on) that were too hard in a single file embedded environment were simply removed.
But the result of this is that SQLite doesn't behave QUITE like a regular database, and sometimes you need to behave slightly differently in order to use it properly.
I've got a number of little programs now that use SQLite data stores, mostly using Class::DBI. But it is starting to gradually rot, and it has more problems than I'm comfortable with.
Most of the other object-relational systems like Rose, Tangram, DBIx::Class, Jifty::DBI and so on, are built first for doing real work on first class databases.
So, for my purposes, they often seem to me to be a bit overengineered when you try to use them as a simple embedded data store.
Now that the CPAN::Metrics module is alive again and I'm doing more work with SQLite databases, this problem is starting to itch a LOT and it's time I scratched it.
So I've started work on a brand new object-relational module that is ONLY able to support SQLite, and has specific behaviors that align to the strengths of SQLite.
It also uses a couple of techniques that are normally frowned on, such as extensive string-evals, APIs that change in response to external conditions, and a connection pooling methodology that would be insane on any database that couldn't do 1000 connections a second.
The goal is two-fold. To keep the code and memory overhead as tiny as possible, and to require as little typing from both the author of an ORLite module, and the users of that module, as I can reasonably provide.
I'll be writing a bit more about ORLite in the coming days, as it gets fleshed out a bit more, but you can get some idea of the concept from the 0.01 version that is now on the CPAN.