suggest DBIx::Concept for module name?

Darren Duncan darren at DarrenDuncan.net
Wed Nov 20 16:07:22 CST 2002


On Wed, 20 Nov 2002, Peter Scott wrote:
> Can you tell me what your module will do that
> http://search.cpan.org/dist/DBIx-Abstract/Abstract.pm doesn't?  That
> would help me.

Yes I can.  However, given that both modules are meaning to solve similar
problems, and would look similar on the surface, I would have to go a bit
more into detail with my answers.  (Note: I downloaded the module and
looked at its source code, not just its documentation.)  For the moment,
here is an unordered list of things that I noticed:

1. DBIx::Abstract does all of its work in a single module, which has to be
updated to add support for new database vendors or improve existing ones;
as that happens, the module gets larger and more complex.  My approach has
a separate module for each database that contains its details; this
separation makes it easier to understand and extend; new databases can be
added as new files without requiring changes to existing files (of
course, similar database-specific files can still be made to subclass
each other).  This is like the approach that DBI itself uses.

2. DBIx::Abstract saves log files of its activity or errors, and makes
use of a global filehandle 'LOG'.  My approach does not talk to the file
system at all, thereby keeping more focused; it returns errors or
debugging info as output to the calling code; users of my modules can use
something else more focused on log-keeping instead.

3. DBIx::Abstract contains at least 1 of what it calls a 'hack' to make
Oracle look like other dbs (in the connection string); the module defaults
to wanting to deal with ODBC style.  Although this in itself may not be an
issue, my approach wouldn't have such 'hacks'.

4. DBIx::Abstract closely ties itself to the existing (although stable)
DBI interface.  A greater part of its functions just pass through to the
DBI function with the same name.  Also, several DBIx::Abstract functions
take DBI objects as input or return them as output.  My approach will have
a fully independent interface which may resemble that of DBI only where it
seems like common sense.  My approach will never expose a DBI object to
the caller, since this breaks my control over the calling interface, and
because I may not always use DBI internally for all databases (although
that is unlikely, I want to be flexible), so it wouldn't be reliable.

5. My approach would provide more functionality than DBIx::Abstract, such
as inserting a whole 'recordset' at once (possibly in multiple related
tables) rather than a single record at once, or such as implementing table
creation and removal, or such as including generically defined subselects
or unions or hierarchical joins or such in select statements, or
implementing 'paging' in select statements like 'return rows 11-20 of
this' or 'resort the list but keep this record in the selected page'.

6. DBIx::Abstract sometimes requires the caller to provide fragments of
literal sql to embed in statements, where I wouldn't.  DBIx::Abstract lets
the caller run any arbitrary sql statement passed in as a string, where I
would require there to be a separately defined 'stored callback function'
that contains the sql instead.

7. I would make it easier to use the 'stored procedure' functionality
built into many databases, as well as to imitate the behaviour that stored
procedures would do in Perl for databases that don't do stored procedures
(the main application wouldn't have to know the difference).  The
application can just do something like '$result = $dbi->my_proc( "arg" )'
rather than '$dbi->query( "CALL my_proc( :OUT_VAR, :IN_VAR )", {} )';
syntax for stored procedures varies by the DBMS.

8. Join conditions don't have to be passed in as a sql fragment with my
approach; rather I would take a list (or an object having a list) of table
fields to match up as well as whether it is equal or outer join etcetera;
this would (especially outer joins) turn into different sql depending on
the database.  DBIx::Abstract doesn't seem to deal with building join
conditions.

9. Technically, my approach will be 'less thin' than DBIx::Abstract, but
it would also be 'more abstract'.

In summary, while I could make change requests to the author of
'DBIx::Abstract' (the likes of which CPAN encourages), I don't think he
will be able to approach what I am offering without rewriting it from
scratch.  There actually are a lot of differences.  So if that's
necessary, why don't I just 'rewrite it'?  And if so, better to have a
different module name so people don't expect it to be
native-backwards-compatible.

Note: My approach is designed to be low-level enough and flexible enough
that most of the existing database abstraction modules could be simulated
or emulated with a separate compatability layer module sitting on top of
mine.  This would help migration, if the move would help anyone.

Scott, If this doesn't answer your question, then please ask me
more detailed questions to flesh it out.

-- Darren Duncan





More information about the Victoria-pm mailing list