[Zope3-dev] Re: RDB support

[Matthew T. Kromer]

Stephan Richter wrote:

> Hello everyone,
>
> as I am getting done writing the server stuff, I am getting ready to 
> integrate RDBs into Zope 3. I have no idea whta is expected of this, 
> but I know I like the way Zope 2 does it. For my taste, porting the 
> Zope 2 mechanism to Zope 3 would be perfect. That would result in the 
> following problems:
>
> Are SQL Methods Content Objects or not?
> Should there be a RDBService having specific implementation utilities 
> as plugins?
> Where do all the objects live? In the Service Manager?
> ...
>
> Let's **constructively** discuss that. I would to agree quickly on an 
> approach!
>

Insasmuch as I dont have the time to devote to this, I find that there 
are some restrictions in HOW SQL methods work, as opposed to their 
user-level syntax; in particular, the notion of collapsing all queries 
to a single string and then passing that string to a "query" method on 
the DA is something I'd like to deprecate in favor of:

a query string constructor which takes a type and a value and returns a 
tuple of (string, value) which the string portion is to be embedded into 
the query string under construction, and the value is to be appended to 
an array of values to be passed to the extended query

an extended query which takes a query string and an array of arguments 
(although some DAs would prefer a dictionary of arguments -- the 
requirement is only that the constructor and query evaluator be 
symmetric -- both functions must be provided by the DA)

The result from the extended query should under no circumstances be 
called a "brain" but rather a "recordset."  Recordsets may have 
abilities like "scrolling" but should be presumed to be a limited view 
(a window) into the results being returned by the RDBMs.  Some of the 
current "brain" functions (which provide synthetic columns, etc) should 
be busted out of the recordset or appended without requiring the DA to 
do much work.

It would be nice to have a smart recordset that could tolerate 
write-back into the recordset and compose a corresponding UPDATE into 
the RDBMS.

There should be some mechanism for invoking stored procedures ala Python 
2.0 DB API.

There should be a better set of defined "discovery" mechanisms, e.g. 
find out the database schemas.

There should be a better way of associating connections with stored 
queries at runtime, such that they can be dynamically assigned by the 
program (to facilitate per-user connections, rather than per-thread 
connections).

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/