Discussion:
DBI Driver Developers BoF at OSCON?
(too old to reply)
Tim Bunce
2004-07-05 19:45:14 UTC
Permalink
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.
David Wheeler
2004-07-05 21:08:05 UTC
Permalink
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'm only peripherally involved in DBD::Pg development these days, but
I'd be happy to attend (provided it doesn't coincide with something I'm
more involved in) and report back to the DBD::Pg developers what went
down.

Regards,

David
John Siracusa
2004-07-05 22:02:39 UTC
Permalink
Post by Tim Bunce
Migration to DBI v2
Speaking of DBI 2, I think I missed out on most of the discussion of what
it's going to include. I found this post:

http://groups.google.com/groups?selm=20040117154056.GA55164%40dansat.data-pl
an.com&rnum=1

Is there a more recent summary of the v2 changes anywhere? Is DBI 2 set in
stone yet, or is the feature set still open for debate?

-John
Tim Bunce
2004-07-06 09:02:43 UTC
Permalink
Post by John Siracusa
Post by Tim Bunce
Migration to DBI v2
Speaking of DBI 2, I think I missed out on most of the discussion of what
it's going to include.
Probably because there hasn't been much :)
Post by John Siracusa
http://groups.google.com/groups?selm=20040117154056.GA55164%40dansat.data-pl
an.com&rnum=1
Is there a more recent summary of the v2 changes anywhere?
There have been no v2 changes yet.
Post by John Siracusa
Is DBI 2 set in stone yet, or is the feature set still open for debate?
It's certainly not set in stone, nor even in jello.

You'll find rough details here: http://search.cpan.org/src/TIMB/DBI-1.43/ToDo

The initial focus will be on changes to the DBI<>DBD interface
(basically the DBI will be providing many more hooks that the drivers
should use instead of their own code to do certain things).
After that changes can be more evolutionary.

Tim.
Greg Sabino Mullane
2004-07-06 00:58:11 UTC
Permalink
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?
I would be interested. Any night except Wednesday works for me,
although OSCON still has an annoying habit of scheduling more
than one BoF I want to attend into the same time slot. :)

- --
Greg Sabino Mullane ***@turnstep.com
PGP Key: 0x14964AC8 200407052059
H.Merijn Brand
2004-07-06 08:10:48 UTC
Permalink
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?
Will you be in Ireland at YAPC::Europe?
Post by Tim Bunce
Migration to DBI v2
Unified test suite
Tim.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Tim Bunce
2004-07-06 08:56:28 UTC
Permalink
Post by H.Merijn Brand
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?
Will you be in Ireland at YAPC::Europe?
Yes, I'm planning to be.

I registered just the other day: http://belfast.yapc.org/register/

Tim.
Post by H.Merijn Brand
Post by Tim Bunce
Migration to DBI v2
Unified test suite
Tim.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
H.Merijn Brand
2004-07-06 10:30:31 UTC
Permalink
Post by Tim Bunce
Post by H.Merijn Brand
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?
Will you be in Ireland at YAPC::Europe?
Yes, I'm planning to be.
Cool. Now they've turned down all my proposed talks (all DBI related), I can
use some DBI-BOF instead.
Post by Tim Bunce
I registered just the other day: http://belfast.yapc.org/register/
Tim.
Post by H.Merijn Brand
Post by Tim Bunce
Migration to DBI v2
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Jeff Zucker
2004-07-06 16:10:58 UTC
Permalink
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
Count me in. Are you thinking of this as instead of, or in addition to
a broader BOF?

I'm a bit squeezed for time prior to OSCON so I'm not going to volunteer
to help organize, but during OSCON, I do live here in Portland, have a
van that holds seven and would be glad to show the local sights natural,
cultural, or beer-ical if we want a change of venue.
--
Jeff
Tim Bunce
2004-07-07 09:27:53 UTC
Permalink
Post by Jeff Zucker
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
Count me in. Are you thinking of this as instead of, or in addition to
a broader BOF?
Ideally in addition to, since it's of little relevant to users at this point.
Post by Jeff Zucker
I'm a bit squeezed for time prior to OSCON so I'm not going to volunteer
to help organize, but during OSCON, I do live here in Portland, have a
van that holds seven and would be glad to show the local sights natural,
cultural, or beer-ical if we want a change of venue.
Yeah!

Tim.
Jeff Zucker
2004-07-08 03:42:29 UTC
Permalink
Post by Tim Bunce
Post by Jeff Zucker
Post by Tim Bunce
Any interest in a DBI Driver Developers BoF at OSCON?
Migration to DBI v2
Unified test suite
Count me in. Are you thinking of this as instead of, or in addition to
a broader BOF?
Ideally in addition to, since it's of little relevant to users at this point.
It looks like Wednesday is pretty booked with BOFs. Tuesday and
Thursday are still pretty open. How about Tuesday for developers and
Thursday for general?
--
Jeff
Darren Duncan
2004-07-08 00:31:46 UTC
Permalink
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
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.
Tim Bunce
2004-07-08 17:37:51 UTC
Permalink
Post by Darren Duncan
I strongly suggest that the standard DBI v2 interface have
native/standard support for named bind variables, in the SQL-1999
style like ":foo".
I hope that will become practical when preparse() is implemented.
Post by Darren Duncan
I suggest that this is not a trivial task
I suggest you're right.
Post by Darren Duncan
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.
Note that the test suite will not be trying to test the database,
just the driver. And only those parts of the driver behaviour
mandated by the DBI spec. Drivers will still need their own tests
for any driver-specific behaviour.

Also note that the "Unified test suite" is a long term goal.
DBI v2.0 is really about infrastructure to the DBI and drivers to
make such things possible. It's not going to happen overnight.
Post by Darren Duncan
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.
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.
I'm not keen on adding another layer of abstration into the mix for
the test suite. However, I will look at it.

Tim.
Honza Pazdziora
2004-07-09 07:06:03 UTC
Permalink
Post by Tim Bunce
Post by Darren Duncan
I strongly suggest that the standard DBI v2 interface have
native/standard support for named bind variables, in the SQL-1999
style like ":foo".
I hope that will become practical when preparse() is implemented.
Could you please point me to some doc / post / thread where I could
find more info about the relationship between :foo and preparse()? I'm
currently supporting ? and :foo in DBD::XBase on the driver level.
It'd be great if I could use DBI for this task.
Post by Tim Bunce
Post by Darren Duncan
I suggest that this is not a trivial task
I suggest you're right.
:-))
Post by Tim Bunce
Note that the test suite will not be trying to test the database,
just the driver. And only those parts of the driver behaviour
mandated by the DBI spec. Drivers will still need their own tests
for any driver-specific behaviour.
The test suite could provide sets of "nonstandard" tests that the
driver author would invoke simply by saying "and run these tests for
qqiweuuqweiw feature as well". Me being lazy, I admit I do not test
everything that would be needed to make DBD::XBase fully tested. If
I could specify what features my driver (= the database) supports and
have tests run for me, that'd be great.

Of course, the ->func calls and driver_ attributes will still need
to be done by hand. But maybe while doing it by hand driver authors
will even find ways of providing the functionality using native DBI
ways.
--
------------------------------------------------------------------------
Honza Pazdziora | ***@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
Only self-confident people can be simple.
Tim Bunce
2004-07-09 10:31:08 UTC
Permalink
Post by Honza Pazdziora
Post by Tim Bunce
Post by Darren Duncan
I strongly suggest that the standard DBI v2 interface have
native/standard support for named bind variables, in the SQL-1999
style like ":foo".
I hope that will become practical when preparse() is implemented.
Could you please point me to some doc / post / thread where I could
find more info about the relationship between :foo and preparse()? I'm
currently supporting ? and :foo in DBD::XBase on the driver level.
It'd be great if I could use DBI for this task.
I've talked about it in the past but couldn't find anything with a
quick google. These two give some idea though:

http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld083.htm

http://search.cpan.org/src/TIMB/DBI-1.43/t/60preparse.t

There's a basic preparse() implemented in C within the DBI but it
doesn't support the brace-escape format and needs to be redone in
pure-perl. That's high on the list for DBI v2.

Tim.
Darren Duncan
2004-07-10 02:14:32 UTC
Permalink
Post by Honza Pazdziora
Post by Tim Bunce
Note that the test suite will not be trying to test the database,
just the driver. And only those parts of the driver behaviour
mandated by the DBI spec. Drivers will still need their own tests
for any driver-specific behaviour.
The test suite could provide sets of "nonstandard" tests that the
driver author would invoke simply by saying "and run these tests for
qqiweuuqweiw feature as well". Me being lazy, I admit I do not test
everything that would be needed to make DBD::XBase fully tested. If
I could specify what features my driver (= the database) supports and
have tests run for me, that'd be great.
Of course, the ->func calls and driver_ attributes will still need
to be done by hand. But maybe while doing it by hand driver authors
will even find ways of providing the functionality using native DBI
ways.
One of the features of the Rosetta API is that the Engine (driver)
you choose to implement the API can/needs-to declare which parts of
the API it supports, and which parts it doesn't (not mentioning a
feature in the support manifest is the same as saying it isn't
supported, giving us forwards compatability).

Essentially, this is a standard way of knowing when to "skip" tests
or not; if an Engine/driver explicitely says that it implements a
feature, then the corresponding tests will run and the Engine/driver
will fail its tests if it fails to do what it says it can.

Extrapolating this out, features that are only available in one
database/driver are visible through the API as an API feature that
only one Engine/driver claims to implement. (Note that, while rare,
the Rosetta API even includes a few features that no database, that I
know of, currently supports, though perhaps ought to. A measure of
forward-thinking if you will. But not unreasonable.)

Note that, aside from knowing which tests to run, one of the main
reasons that Rosetta has the feature manifest is so that applications
built on top of the API can declare explicitely what database
features they require, and it will be easy for them to
programatically detect which Engines/drivers the application can use.
That useable set contains the Engines/drivers which claim the
required features and pass the tests for them.

Note that, technically, having a driver claim "I support this" is
referring to the combination of the driver and the database engine.
It is quite normal, if perhaps slower, that some features will be
implemented or emulated in the driver itself, and not the database.
It is up to the Engine/driver writer to decide. But then, thats what
DBD modules already do with DBI; for example, they emulate "?"
place-holders when the database itself doesn't do it.

-- Darren Duncan

P.S. If you're wondering why I use the word "Engine" instead of
"driver", it is because the way I look at this, if the system were a
car, then the driver is the application, since it says what to do and
when, the Rosetta API is the dashboard, steering wheel, etc, and the
Engine is what makes things happen when the controls are pressed. In
my model, the Engine is the sum total of the database itself and the
Perl glue between it and the API. I note that this analogy works for
both client-server and embedded databases, where in some cases the
DBD module *is* the database. Still, this is just technicalities or
terminology.

Continue reading on narkive:
Loading...