Re: Considering future support for different databases.

[jbert]

Mogilefs is a significant perl app which is database-independent between MySQL, Postgres and SQLite.

Basically, the approach is to have a 'store' base class which encapsulates all db access.

There are capability flags set by each concrete derived store. e.g. 'can_replace' returns true in MogileFS::Store::MySQL, but false in MogileFS::Store::Postgres.

This allows methods like:

sub ignore_replace {
    my $self = shift;
    return "INSERT IGNORE " if $self->can_insertignore;
    return "REPLACE " if $self->can_replace;
    die "Can't INSERT IGNORE or REPLACE?";
}

to try and do something sensible depending on the back-end.

But frankly, you're going to have db-specific bugs unless you've got good test coverage. And db independence gets harder the more of the db features you use (both because you have to check for more variation and because such things are less standardised).

[Cap'n Steve]

That's an interesting example, but I don't think I'd like dealing with it that way. It looks like it could be more work (figuring out the individual features each database supports, especially for complicated queries), and I don't think it's very readable.

[mr_mischief]

It wouldn't have to be all methods. You could use a hash for each database, with keys for the capabilities and the actual SQL you need for your particular action. These could be complete with the placeholders already present. Then, you could assign a reference to the proper hash for your DBM to a global scalar. OTOH, a good reusable framework takes a lot of work, and there are a few to choose from that have that work already done.