[ZODB-Dev] SQL/ZODB integration (was Re: ZODB and new style classes?)

Phillip J. Eby pje@telecommunity.com
Mon, 01 Jul 2002 15:14:57 -0400


At 02:52 PM 7/1/02 -0400, Jim Fulton wrote:
>
>That's very cool and encouraging. The current APIs are, at best,
>inelegent. _p_jar and _p_changed come to mind. :)

Just when I was getting used to them...  Ah well.  :)


>I spoke to someone at EuroPython who was working on an EOF persistence
>framework. He seemed to want an observer mechanism to enforce integrity
>constraints.  BTW, I think that there was some interest on a standard Python
>observer mechanism that could, possibly allow the persistence mix-in
>to be avoided.

I'm not very concerned about the mixin, since my goal isn't to persist
arbitrary objects, but to support creating objects that are persisted.
Ideally, though, I'm trying to stick with one base class usable for any
back-end, including traditional ZODB.

(By the way, it might be good to have terminology to distinguish between
ZODB as a persistence framework (the persistence and transaction packages)
versus ZODB as a framework for a particular family of persistence
mechanisms (the part that lives in the ZODB package proper).


>I'd like to formulate a cleaner interface between the caching architecture
>and the persistance framework. For example, currently, the persistence
interface
>includes cache-specific data, which is silly.

I agree.  Some other way to hook access interaction would be helpful.
Notably, as I just mentioned to Shane, it would be nice to be able to track
what objects were accessed (non _p_-attributes) in a transaction whose
state was not loaded in the transaction.  (That is, to track accesses to
potentially-stale cached objects.)  This might be helpful for more-thorough
conflict detection, for example.

Anyway, if you want to talk about ideas, I have bandwidth on this issue
available right now.  It's important to projects I've got going on and time
is a factor.  Heck, I might be able to get the company to spring for a
"sprint" here on the issue, although I haven't talked to anyone about such
an idea yet.

Perhaps it would be helpful to start by clarifying some of the requirements
for the new interface?