Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday September 19, 2008
12:07 AM

ORLite 0.13 and ORLite::Mirror 0.07. Now they do less!

[ #37490 ]

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;

use ORLite {
        file => '/some/file.sqlite',
        tables => 0,
};

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.

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.