[Zope-DB] wishlist

[Matthew T. Kromer]

kapil thangavelu wrote:

>On Thursday 20 September 2001 12:42 pm, Matthew T. Kromer wrote:
>
>>This is a direct consequence of the data being sent into the database as
>>strings, not as positional parameters.  I would guess that ZSql methods
>>can be tweaked by simple re-coding to allow you to embed a line-end
>>character for SQL -- but my preferred solution is to try to use bind
>>values instead (which Zope does not support at this time but is on my
>>wish-list to pull some patches and do some other work to support.)
>>
>
>
>Hi matt,
>
>i'm trying to make a zope db wish list for things to do in a rewrite. so far 
>the major things i have are
>
> - connection state management
> - bind variable support 
> - allow for explicit transaction control
> - general code clean up.
> - integration with cache manager api
>
>i was wondering if you would mind sharing whats on your wish list...
>
>thanks
>
>kapil thangavelu
>
Well, my use of the term "wish list" is mostly idiom, but you've covered 
most of the things I'm unhappy with. I also agree with Andy, that I'd 
like to have a very full testing suite for API compliancy.   One wonders 
if opening up the CVS repository will significantly foster growth of 
test suites (my test cases are mostly ad-hoc programs designed to test 
one or two features, not a *validation* suite).

I specifically want to break apart Aqueduct into two components, such 
that DB connection foundations are one piece, but the query generators 
etc are another.   (Aqueduct is Shared.DC.RDBMS).  

In particular, it's probably [way past] time to write a formal API 
description of how it SHOULD work from Zope, not how it DOES work (which 
is more or less "it does what it does").  In particular, this should 
address various issues related to DB discovery, such that product 
authors can write tools to help query generators assemble queries, etc, 
so the end user does not have to be too sophisticated in the knowledge 
of the schema or SQL.   This does not mean that the revised code will 
USE the features, as much as it does that it forms a better foundation.

However, much of the time, this means finding RDBMS abstractions that 
hide nuances of the various underlying implementations, and that is 
often highly problematic.  I'd like to be able to see session-correlated 
connection pooling, for example -- so you could have a per-user 
connection to the RDBMS (given certain constraints, anyway) rather than 
per-thread.