July 28, 2004 Archives

Tuesday late afternoon Vani and I went to dinner with Tim at Veritable Quandary. Food was great, even if we ended up inhaling the desert to make it back to Tim's DBI Driver Developers BOF.

If DBDs are upgraded they can be made to work with both (new) 1.x DBI versions and with 2.x DBI.

DBI trace level will be a bitmask instead of just a number. 8 bits will be reserved for drivers. There'll also be "trace keywords" with levels independent from the general trace level.

dTHR will be mandated in the drivers for DBI 2 which will make DBI slightly faster in embedded and threaded eenvironments (mod_perl 2).

$sth->reset (name to be determined) method to reset the statement state (call finish, reset attributes etc). This is to allow passing in handler attributes when you run prepare and to be able to run prepare again on a $sth.

unicode: maybe there'll be some utility functions for the drivers to use, but essentially it'll still be up to the drivers to do the appropriate thing for the database. Matt suggested writing up strong guidelines for how the DBDs should work. He was then volunteered to do it. :-)

Preparse magic: makes it easier to move SQL from one database to another.

Improving the test suite so the same test suite can be used by all the different drivers. So if you start writing a new driver you'll have an instant test suite. It'll also help making sure the driver behaviors don't divert in subtle ways.

There's also the DBI TODO (username and password is guest).

Tuesday morning I stopped by a few minutes of Joe Celko's Advanced SQL Tutorial. Joe has an amazing knowledge of the SQL language, no doubt. Lots of arcane knowledge and references to "when we had the discussions in the SQL committee we did discuss that". But the tutorial was a bit too DBAish for me. By that I mean too much "this is how data should be neat" rather than "this is how you solve real business problems". While I was in there he was talking about not inventing new ids for something that already have standard IDs. For example vehicles have VINs, so you shouldn't invent your own primary keys. The pragmatic programmer in me screamed "but what when you need to add a record for a vehicle you don't have a VIN for yet" (insurance agent adding a new car to a quote so the customer can just call with the VIN to finish it up later or whatever). Anyway, so after seeing that kind of thing a few more times I left.

In the afternoon I stopped by Jeremy Zawodny's MySQL Performance Workshop. Lots of good, even great, tips and hints on things to do to test and improve MySQL performance. But alas, in the time I was in there I didn't pick up anything I didn't already know. (I've used MySQL for how many years now? 7? Is that even possible?)