I really want to use ORLite as the interface to the SQLite datastore for Padre, since it's so awesomely appropriate for that sort of thing.
But the problem is that Padre currently uses manual DBI code, and moving directly to fully abstracted object models is hard.
What I'd really like to start with is to move to the SQLite-specific DBI wrapper base class that ORLite provides (which rocks, especially for transactions) but without generating all the automagic ORM tables.
So now you can do the following and you get just the base layer.
package Padre::DB;
Thus, you now have an easier path for porting regular DBI code towards the object model, but don't have to go all the way immediately.
use ORLite {
file => '/some/file.sqlite',
tables => 0,
};
Pushing the concept out to the remote case, you can also do the same thing in ORLite::Mirror as well.
use ORLite::Mirror {
url => 'http://cpants.perl.org/static/cpants_all.db.gz',
package => 'CPANTS',
tables => 0,
};
This lets you create a super simple DBI-like database class for a remote database and run ad-hoc queries, but without having to go the whole hog of generating and using an object model.
And because ORLite has almost no dependencies, using such a limited subset of features isn't bloating dependencies. You just aren't using the 300 or so lines of ORLite code that generates the model.
