Proposal Database::Initialize::Postgresql (naming okay?)

I've got a question about naming a module I'm about to finish up
and put up on CPAN. At present, it's essentially it's a set of
routines that run SQL scripts that initialize a database schema
for a particular project. It also includes features to drop a
schema, and a key feature (for me at least) is that it refuses to
do this unless the schema is named something like "*_test".

I'm leaning towards calling this:

Database::Initialize::Postgresql

Though currently, on my box, it's called:

Database::Util::Postgresql

Here's the SYNOPSIS for the code as it stands:

use Database::Util::Postgresql;

my $dbname = "new_project_test";

my $dbuh = Database::Util::Postgresql->new(
$dbname,
$db_user,
$db_password,
{ create_script_sql => $create_script_sql,
initialize_script_sql => $initialize_script_sql,
drop_script_sql => $drop_script_sql,
clear_script_sql => $clear_script_sql,
}
);

$dbuh->drop_test_database( $dbname );
$dbuh->create_database( $dbname );
$dbuh->initialize_database( $dbname );

I will probably modify this UI to take either an external file
name, or chunks of SQL passed in via strings.

There are also some random utility methods in the present
version, which do things like check for the existance of
"dbnames", list table names, get the number of rows in a table,
get the last id of the last row insert, and so on... I expect
that I'll move some of these into another "Util" module (which
may or may not end up on CPAN).

As for the naming issue: I think "Database" is better than "DBIx",
because this code doesn't exclusively go through DBI (much of it
just shells out to "psql", the postgresql command-line monitor).
Also, it would be difficult to remove the Postgresql specific material
to justify the "Independant" that "I" stands for.

Putting it in the Test::* hierarchy doesn't make sense to me,
because the test features are only part of what it it's for. I
also use it to initialize a schema the first time some code is
run.

I'm inclined to keep this out of the DBIx namespace because it
doesn't exclusively go through DBI, and there's a lot of
Postgresql specific stuff in it that would be hard to remove

I think spelling out the name "Postgresql" in full is the only
reasonable thing to do, though unfortunately various
abbreviations are in use in different places (e.g. "DBD::Pg").

I think I prefer this order of terms:

Database::Initialize::Postgresql

Because hypothetically it might be possible to create a less
database-specific version of this:

Database::Initialize

But considering that I might release a few things like this,
(and other people might do ones for other databases) I could
see an argument that it might make sense to handle the namespace
like this:

Database::Postgresql::Initialize
Database::Postgresql::Util

So what do you all think? Any other ideas?

Re: Proposal Database::Initialize::Postgresql (naming okay?)

Joseph Brenner wrote:
> I've got a question about naming a module I'm about to finish up
> and put up on CPAN. At present, it's essentially it's a set of
> routines that run SQL scripts that initialize a database schema
> for a particular project. It also includes features to drop a
> schema, and a key feature (for me at least) is that it refuses to
> do this unless the schema is named something like "*_test".


>
> Because hypothetically it might be possible to create a less
> database-specific version of this:
>
> Database::Initialize
>
> But considering that I might release a few things like this,
> (and other people might do ones for other databases) I could
> see an argument that it might make sense to handle the namespace
> like this:
>
> Database::Postgresql::Initialize
> Database::Postgresql::Util
>

how about using a factory method:

my $dbuh = Database::Initialize->getInstance(
"postgresql",
{ user => $username,
password => $password } );
$dbuh->drop_test_database( $dbname );

thus ensuring consistent syntax across implementations.

Mark

Re: Proposal Database::Initialize::Postgresql (naming okay?)

Mark Clements writes:

> Joseph Brenner wrote:
>> I've got a question about naming a module I'm about to finish up
>> and put up on CPAN. At present, it's essentially it's a set of
>> routines that run SQL scripts that initialize a database schema
>> for a particular project. It also includes features to drop a
>> schema, and a key feature (for me at least) is that it refuses
>> to do this unless the schema is named something like "*_test".
>
>
>> Because hypothetically it might be possible to create a less
>> database-specific version of this:
>> Database::Initialize
>> But considering that I might release a few things like this,
>> (and other people might do ones for other databases) I could
>> see an argument that it might make sense to handle the
>> namespace like this:
>> Database::Postgresql::Initialize
>> Database::Postgresql::Util

> how about using a factory method:
>
> my $dbuh = Database::Initialize->getInstance(
> "postgresql",
> { user => $username,
> password => $password } );
> $dbuh->drop_test_database( $dbname );
>
> thus ensuring consistent syntax across implementations.

So your idea would be write a "Database::Initialize" that's essentially
an interface, and have it access "Database::Initialize::Postgresql"
(or whatever) as a plug-in, or driver? That sounds like a reasonable
architecture.

That would open up the door to the notion that perhaps it should be
in the DBIx namespace... but then, the database-specific backend
might or might not go through DBI, so "Database" would still seem
like the better choice to me.