[VPM] [RFC] naming a module for SQL routines
Darren Duncan
darren at DarrenDuncan.net
Sat Sep 18 02:04:52 CDT 2004
This is a request for comment with the intent of determining a better
name for one of my CPAN modules prior to it being registered with the
Perl 5 Module List. The module in question has been using the name
"SQL::SyntaxModel" since about September 26th of 2003, following a
previous RFC process which seemed to favor that name, but not
unanimously. I have thought of some new ones, given below, and
welcome feedback on them or further suggestions.
Please send all replies to both the list(s) and directly to me.
I had been satisfied with the current/old name so far, but this has
changed during the last few days. For one thing, there has been
resistence from the module list and alternate suggestions that I
didn't like. For another thing, it seems that my module has evolved
significantly since last year's RFC process, and so I am open to a
new name that is adapted to the module's shifts of focus.
Some constraints that the new name must follow:
1. It must be a noun, rather than a verb. The module is a rigorously
structured data container, and doesn't do anything besides storing
data within its own Perl variables. The name should represent what
it *is* rather than what it does. It is external code which uses the
module that does any "doing".
2. It must be a level-2 name, under the SQL::* name space, like
"SQL::*". SQL is the problem domain which the module addresses, so
it would fit best with the other SQL::* modules, that also address
this problem domain, such as SQL::Statement. At the same time, this
module stands alone, is not based on or designed explicitly to work
with any other module, and is not one parallel member of a larger
framework, so a level-3 name (SQL::*::*) is not appropriate.
3. The second-level portion of the name should be composed of only
one or two words, like the other SQL::* modules are, and the old name
is.
FYI, this is a list of other CPAN modules that I have identified
which exist in the same problem domain (there are probably more):
SQL::Statement SQL::Translator SQL::YASP SQL::Generator SQL::Schema
SQL::Abstract SQL::Snippet SQL::Catalog DB::Ent DBIx::Abstract
DBIx::AnyDBD DBIx::DBSchema DBIx::Namespace DBIx::SearchBuilder
TripleStore
As usual, this new name should highlight what makes my module unique
compared to the other CPAN offerings, including what its focus is and
what it does best; hopefully that is one and the same of saying what
it *is*.
A few new ideas of my own:
- SQL::SchemaModel (note for similarity that "SQL::Schema" is already
taken by an existing framework that hasn't been updated in over 4
years)
- SQL::RoutineModel (no similar names)
- SQL::Routine (no similar names)
- SQL::Routines (ditto)
Under the circumstances, I am leaning towards the "Routine" set,
partly because no name even similar exists on CPAN.
The main reason concerns a revisiting of one of the module's main
intended uses, which was to support the idea of any database-related
activity being representable by a SQL routine or imitation thereof.
An implementation of a SQL routine that my module
describes/models/defines could either be stored in a database schema
(eg: as a SQL stored procedure, function, or trigger), or it could be
stored on the client/application side (eg: as a fusion of Perl code
and DBI calls). But from the application's point of view, the
routine simply exists in a locally addressable space and can be
invoked more or less like a Perl routine (function or procedure),
regardless of whether it is actually in the database or on the client.
A routine is quite generic in scope and can hold complete
instructions for any kind of database activity, including arbitrarily
complex select queries, DML, schema creation or manipulation, user
management, transactions, and connections. Therefore, saying that my
module supports or models routines means that it supports and models
all types of SQL. It was also designed in the hindsight of
SQL-2003, and is not limited to SQL-1992.
But while my module can represent SQL effectively, it is not exactly
the same as SQL, and can be used with both databases or applications
that don't want to talk SQL. Hence, calling it a "SyntaxModel" is
somewhat archaic.
The module is designed with a strong emphasis on portability, and it
is expected that one should be able to use it effectively when
porting an application between databases and/or porting a database
schema (plus data) from one product to another, including advanced
databases having multiple schemas per catalog, or schema objects for:
domains, schema generators, tables, views, routines. All schema
objects, as well as client-side SQL, is broken down to an atomic
representation that can be easily understood by a computer, and
effectively converted with whatever variances are required by
different products. This not only means being converted into SQL,
but also converted into Perl code when you want to emulate certain
features that a database engine doesn't natively support. Even some
SQL can emulate other missing SQL features, such as emulating SQL
unions or intersections with SQL join operations. My module makes it
a lot easier for external code to do this.
I am resistent to using any names which describe too much about how
the module is internally structured. For example, I don't want to
use the word "tree" anywhere even though the module POD mentions that
word constantly.
So my alternate suggestions are:
a. A focus on the fact it can represent complete schemas, both
database-side and application-side, which include routines.
b. A focus on the fact that it represents everything with routines.
Barring any further suggestions, I'm leaning towards the latter.
However, there is another matter to keep in mind when picking a name.
For one thing, each primary object produced by my module can and does
represent an entire set of SQL routines at once. In fact, the
intention is that a typical application will only ever use a single
"Container" object in which lives all of their database and
application descriptions, whose definitions overlap.
One thing that concerns me is that a name like "Routine" may suggest
that each object just represents a single routine, rather than a
related set of them; "RoutineModel" seems less likely to suggest
this, though I could be wrong.
So I welcome feedback on these matters. Eg: Am I worried about
nothing with the one-vs-many implications? Which of "SQL::Routine"
or "SQL::RoutineModel" is better? Or is "SQL::SyntaxModel" still
best of all? And what other good suggestions are there, if any.
Reasons are always helpful, but not required.
At the very least, I would like to end up with a situation where
multiple people agree that one choice is best, the more the better,
and a consensus best of all.
Thank you very much in advance for any help. I really appreciate it.
-- Darren Duncan
P.S. Some helpful urls, but the documentation focus is out of date
relative to what I said above, as well as some structural issues:
http://search.cpan.org/dist/SQL-SyntaxModel/
http://search.cpan.org/dist/SQL-SyntaxModel/lib/SQL/SyntaxModel.pm
http://search.cpan.org/dist/SQL-SyntaxModel/lib/SQL/SyntaxModel/Language.pod
P.P.S. The module is close to completion, so about 90% of what you
see now in the module should stay that way for awhile.
More information about the Victoria-pm
mailing list