Jens Rehsack wrote:
during refactoring of DBD::File and new wishes (e.g. SQL_IDENTIFIER_CASE
from Martin Evans, getinfo() support, ...) and my own try of a pure-perl
DBD for system tables (DBD::Sys) I see many common code.
I would like to extract the common code into a base class DBD - maybe
named DBD::SQLPerl (placed SQL in from for private methods and attributes
naming - the should have the prefix "sql_").
I had already been thinking of this need for awhile, but in that context it
would have been a utility module, say with "common" in its name or something.
Unless there is already a precedent otherwise, I recommend leaving the DBD::*
namespace for actual DBI drivers, and utilities go in some other namespace,
though perhaps DBD::Util::* or something.
The choice may also be affected by whether the new module is meant to be
subclassed by a DBI module or just "used" ... the latter makes more sense if it
would be used by multiple component classes like the driver and statement
handles, unless the utility has one for each of those, but I wouldn't make it a
subclassing situation.
YMMV.
In any event, I intend to personally be doing akin to what you propose but more
comprehensively, sometime around the August-September 2010 timeframe. For about
that time I would be making the reference implementation of my Muldis D
language, which is a self-contained Perl relational DBMS with nearly all the
features you'd see in a regular SQL DBMS, including multi-column joins,
subqueries, unions, recursion, nested transactions, etc.
This would be componentized such that most of it could be reused directly as
utilities to do what you want, such as by adding a SQL parser on the front and
changing the storage end to talk to the system metadata or Google or CSV files
or whatever.
Don't let that stop you from doing what you're doing though, which looks like
more of a refactor, but I do intend to take it to the next level before long.
-- Darren Duncan
P.S. See also Genezzo.
