Are any/many driver authors/maintainers/patchers going to OSCON this year?
Any interest in a DBI Driver Developers BoF at OSCON?
Main topics would be:
Migration to DBI v2
Unified test suite
Tim.
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 out, though.
Meanwhile, I do have a few specific suggestions or announcements that hopefully can be applied at that meeting, or on this discussion list before hand.
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 the interface.
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 days.
