Post by Tim Bunce
Are any/many driver authors/maintainers/patchers going to OSCON this year?
Any interest in a DBI Driver Developers BoF at OSCON?
Migration to DBI v2
Unified test suite
I would be interested in taking part in this, if not for the fact
that I can't attend OSCON this year. Maybe in 2005 it would work
Meanwhile, I do have a few specific suggestions or announcements that
hopefully can be applied at that meeting, or on this discussion list
First, a DBI v2 suggestion:
I strongly suggest that the standard DBI v2 interface have
native/standard support for named bind variables, in the SQL-1999
style like ":foo". If the underlying database supports it, then that
feature can be accessed, if not, then it can be emulated; in both
cases, similar to how the positional "?" bind variables work now.
Besides making SQL easier to read / more self documenting, it is a
great efficiency step when the same actual bind value is being used
multiple times. Then execute() can take a hash ref argument whose
keys are the same but without the leading ":", and the values are the
values, rather than taking an array, unless the bind_param()
functions are used instead.
Second, about the "Unified test suite":
I suggest that this is not a trivial task, considering that a
thorough test suite would try to exercise all of a database engine's
capabilities to make sure they can be accessed properly, being able
to take any valid input and return any type of output. Moreover,
while adherance to the ANSI/ISO standards help greatly, there is
still a wide variety of ways to do most of these tests, due to
different support for SQL, either in syntax or in behaviour.
Since Tim doesn't, as I recall, want to deal with non-trivial SQL
parsing or generation in the DBI core/foundation, and rightly so for
simplicity, I propose that there can be a second standard layer on
top of or integrated into (but separable and optional from) DBI which
does this. The layer would provide a second level of abstraction,
doing for SQL what DBI does for the C driver APIs, which is make them
look identical to the end-user. It would be optional for people that
want to work in the database engine's native dialect for some reason,
but probably would be used by default by many developers because it
makes things easier.
If the unified test suite were written to use this second layer, then
it could be a lot less complicated, only having to deal with a single
version of many details where it otherwise had to have several, which
would take away from its desired unified characteristic.
I propose that my Rosetta module/framework (including
SQL::SyntaxModel) could be used for this purpose. In fact, it was
largely created for this purpose in the first place, to become a sort
of hidden standard. Rosetta is not intended to replace the other
DBIx/etc "abstraction layers" that sit on top of DBI now, in that it
would typically be used by an end-developer. Rather, it is intended
to be used by said DBIx modules internally to help them do their job.
In fact, Rosetta's API is somewhat too verbose for the average
end-programmer, and is intended to be used beneath "simplifying
methods". More to the point, I propose that the Rosetta API be used
by the unified test suite so that suite can be more effective at work
and easier to develop.
For those of you with long memories, you may have noticed that I
announced or proposed this framework before, since the earliest plans
for it were uploaded to CPAN on 2003.01.06. However, I largely
stayed quiet about it because the framework wasn't ready to be "used"
yet. I speak up today because the wait time is nearly over. I have
started writing the Rosetta::Validator module this very week, which
implements an actual set of tests that can be run against any
database, written to the Rosetta API. The basic idea is that someone
runs this Validator module after installing the framework, and if its
tests pass, then you have proof that the database is useable through
I plan to upload the first FUNCTIONAL version of Rosetta, with the
Validator module that proves it, within the next few days, or at the
latest, a few days prior to OSCON (more likely). Then you can
actually try it out and see if it provides a valid point of departure
for the Unified Test Suite being discussed just after at OSCON.
In conclusion, I regret not being able to attend OSCON, but I wish
that any of you who are there will have a good time.
Thank you. -- Darren Duncan
P.S. I will be away from home July 13th-19th, so no uploads will
happen on those days; anything will happen before and/or after those