[ZODB-Dev] I want Object Gadfly

[Phillip J. Eby]

At 10:45 AM 7/18/03 -0400, Jim Fulton wrote:
>- Relations should be implemented via Object Gadfly (or something
>   like it). Object Gadfly is Gadfly implemented over ZODB.  It
>   allows you to use SQL (and presumably other sorts of analysis)
>   against relations (tables) stored in the ZODB. These relations
>   can contain any objects.
>
>   With Object Gadfly, you can create relations between objects using
>   content-space tables or named site-wide utilities. Data can be added
>   to them explicitly, or automatically via event subscription. Tables can
>   be indexed and you can execute automatically optimized queries against
>   them using SQL.
>
>Unfortunately, Object Gadfly doesn't exist. :(
>Any takers? :)
>
>Notes:
>
>    . Despite references to Zope concepts like
>      hubs, content and utilities, Object Gadfly need have
>      nothing to do with Zope.
>
>      Object Gadfly need not be ZODB specific.
>      It only needs to have an open enough storage model to allow
>      ZODB to be plugged in.

Hm, Jim Fulton considering the use of SQL?  What's this world coming to? ;)

Seriously, though, I would mention that there are a few open source Java 
projects (e.g. Hibernate and Castor) that include SQL/OQL engines.  Mostly 
these live atop relational mappings rather than object databases, but a lot 
of the fundamental logic is there.  I planned to eventually raid these 
myself when I got to the point of needing/wanting an SQL/OQL mechanism.

Somewhat more near term, I've been thinking about creating a "tabular data" 
API for doing queries and modifications to tabular data.  Coming up with a 
suitable API for this would allow query languages and the like to be 
written over it, and shared across multiple implementations.  One of the 
things I think interesting is the potential to use object adaptation to 
transform generic criteria specifications into backend-specific 
criteria.  One could have the query language express generic constructs, 
and backends could adapt them to constructs that are actually executable.

Obviously, this is all relatively vague in my mind at present, as it was 
going to be months away on my radar.  But I'm certainly interested in 
participating in the design and or execution of parts of it.  One of my 
itches in this area is that compared to Java JDBC, the Python DBAPI is 
incredibly more sensitive to differences between databases.  Being able to 
abstract that and other issues would be really nice.