[VPM] Re: [RFC] naming a module for SQL routines
darren at DarrenDuncan.net
Sat Sep 18 14:17:23 CDT 2004
Thanks to Peter Scott for being the first to reply.
Just to make clear, the module I'm asking to have named today is just
a container that defines actions which can be done against a
database, but it does not actually talk to any databases or otherwise
execute the definitions.
Therefore, "[dbms-related-thingy]::Mechanize" might be a good name
for another module which uses mine and performs the actions, but not
for my module itself. AFAIK, WWW::Mechanize actually "does" the
stuff that it models.
I also want to head-off any false impressions I may have caused when
I said "it is not exactly SQL". That comment was more of a reference
to fringe cases such as older or non-standard databases, or services
that want to be used like databases, that don't use SQL. In fact I
expect that most uses of my module will be in connection with
databases that do understand SQL, and SQL will be generated from my
module's objects to be their input. For the other cases, think of my
module as a better attempt to bring SQL to those that know it not.
I do not feel that the "DBIx" namespace is appropriate because that
namespace is for modules that explicitly extend and/or depend on the
DBI library, and this module of mine does not. It can be used with
DBI, where external code provides the bridge, but it doesn't have to
be. I also consider that DBIx modules are usually all "doer" modules.
I appreciate your suggestions, though; they may get used elsewhere.
For everyone's information, after I've given this more thought, I'm
currently leaning towards one specific name, which is "SQL::Routine".
I decided not to worry about the perception of "represents one vs
many". People could think of that name as conceptually being "not
just one SQL statement but a whole bunch".
Do any of you think that "SQL::Routine" can work best, or do you
favor something else?
Thanks in advance. -- Darren Duncan
At 10:29 AM -0700 9/18/04, Peter Scott wrote:
>At 12:04 AM 9/18/2004, Darren Duncan wrote:
>>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.
>This is a bit off the wall, but after giving this considerable
>thought, what comes to mind is SQL::Mechanize, after WWW::Mechanize.
>>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.
>Given this, perhaps DBIx::Mechanize would be more appropriate. YMMV.
More information about the Victoria-pm