[ruby-dbi-users] 0.4.0 postmortem and RFC

Erik Hollensbe erik at hollensbe.org
Fri Aug 29 22:17:39 EDT 2008


First off, sorry this is so long. Second, if you are experiencing the Pg DBD 
problem KUBO Takehiro mentioned earlier or the MySQL problems discovered by 
Pistos, expect a resolution in the next day or two. 

There are a couple of things that need to be addressed before we can continue 
with 0.6.0. Anyone who's compared 0.2.0 (which is really just 0.1.1 with some 
bugfixes) to 0.4.0 knows that I took a very large, fast moving hatchet to a 
lot of things in the existing architecture and added a few things that aren't 
backwards compatible.

0.4.0 took way too long to get to rubyforge and I'm the only one to blame for 
that.

I certainly am aware that DBI has plenty of unresolved issues and the goal is 
to resolve these instead of just acknowledging they exist and complaining 
about them. If you have comments on 0.4.0 flaws, or what you'd like to see in 
0.6.0, please attach them to this thread or in the tracker. I'm not expecting 
patches for these issues, just information on them and any opinions that come 
with them. Please keep our goals in mind, they are explained at http://ruby-
dbi.rubyforge.org/

Feel free to open the flood gates, the point here is to build a better tool, 
not beat chests. It would be nice to keep the personal attacks to a minimum. 
Brainstorm your eyes out, nothing is sacred for this exercise.

Anyways, here is a terse (yes, really) list of things both proposed to me and 
thought of by me that are on the possible changes list:

- Proxy and Trace fixed and working
- DBI.connect should have consistent arguments, should not rely on DBD 
interaction at all. This mainly involves the parsing of "enhanced" connect 
strings and arguments
- provide a well-defined spec for the above; how db-specific parameters are 
defined and how parameters interact with the system in general.
- gem interaction with methods like available_drivers
- outbound binds (this was planned for 0.4.0, scrapped for time)
- enforcing API for columninfo, etc (DBDs must return these fields in these 
cases)
- test system that can test DBDs independently
- better thread support
- axe case-insensitivity for driver names in connect strings; this is the 
cause of a lot of error-prone code in the core.
- a more complete SQL parser for DBDs that don't provide, or want to use, 
native binding APIs.
- better definition of where binds can be used, or context-sensitive binds 
(e.g., most native binding APIs don't allow a bind for the table name or 
syntax keywords, should we continue to allow this at all, or constrain it to a 
different type of bind?)
- a more interactive method of scrolling fetch cursors (see fetch_scroll())
- better support for windows users.
- appropriate SCM support for developing the bundled DBDs and DBI 
independently.

I'm sure I missed a few things already stated, so please chime in if I did.

Thanks for your time,

-Erik


More information about the ruby-dbi-users mailing list