[Persistence-sig] "Straw Baby" Persistence API

[Phillip J. Eby]

At 04:12 PM 7/22/02 -0400, Jeremy Hylton wrote:
> >>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>   PJE> * Flag _p_changed *after* __setattr__, not before!  This will
>   PJE> help co-operative transaction participants play nicely
>   PJE> together, since they can't "write through" a change if they're
>   PJE> getting notified *before* the change takes place!  Docs should
>   PJE> also clarify that when set in other code, _p_changed should be
>   PJE> set at the latest possible moment, *after* the object is in its
>   PJE> new, stable state.
>
>Can you flesh out this request?  The second sentence there suggests
>interesting issues, but doesn't spell them out.
>
>As for when _p_changed should be set: Why does it matter?

Because setting _p_changed triggers a notification to the DM, which may 
need to perform an immediate save of the object's state, if a transaction 
commit is already in progress.


>   PJE> * Get rid of the term "register", since objects won't
>   PJE> "register" with the transaction, and neither should they with
>   PJE> their data manager.  They should "inform their data manager"
>   PJE> that they have changed.  Something like an objectChanged()
>   PJE> message is appropriate in place of register().  I believe this
>   PJE> would clarify the API.
>
>I don't have a problem with register().  In what way is the current
>interface unclear?

"register" doesn't mean anything in the context of a data manager.  It made 
some sense in reference to a transaction - presumably something registering 
with a transaction is some sort of transacted thing.  Registering with a 
data manager, however, doesn't say anything about what it's being 
registered for or what this will do.  "objectChanged()", however, would 
clearly state that this is a notice that an object has been changed.

Also, "register" implies implementation that may not exist!  Some data 
managers may save changes immediately, and not "register" anything about 
the object or the change.  (Think, for example, of a chat room object 
implemented via a persistence mechanism.)


>I'd like to see some comments from people who haven't already used
>ZODB.

I'd like to see some, too!  If it was just going to be Jim and me we 
could've taken it to private e-mail and avoided having a SIG.  :)


>   I worry that all the comments are coming from a small number of
>people who wrote or use ZODB's persistent mechanism, and that we'll
>make decisions will be limiting for other persistent applications.
>(But maybe there aren't any other such applications/users.)

Personally, I'm trying to speak as someone who has *wrestled* with ZODB, 
trying to make it do things it's not entirely suited for.  As pro-ZODB as I 
may sound in some ways, my needs are pretty diametrically opposite a *lot* 
of ZODB's design parameters.  I want:

* Transparent use of legacy databases w/fixed schemas (vs. new DB format, 
fluid schema)

* Strongly transactional caching (vs. out-of-date reads of objects not 
written in that txn)

* High write-to-read ratio (vs. high read-to-write ratio)

* Use DBMS indexing and query capabilities (vs. creating them "from scratch")

* Undo and versions optionally handled at the application domain level (vs. 
building them into the infrastructure)

If you can think of a ZODB design parameter that I *don't* want the 
opposite of (besides things like lightweight, high performance, low memory, 
easy to use, etc., that nobody in their right mind would disagree with), 
please let me know.  :)

So, given that I'm so "opposite" in my needs, I think it's really quite 
impressive that it can accomodate me with so little stretching.  There 
isn't anything I've proposed in Straw Man and Straw Baby that I can't do 
with the existing ZODB 4 code, if I'm willing to hack at it a bit.  Okay, 
maybe more than a bit.  But it's at least *possible*.

Honestly, I was and am much more disturbed by the possibility of ZODB 4 
undergoing an API upheaval, than I am about not getting every little thing 
I want.  A de-facto "standard" framework that I can work around, is better 
for me than a fast-moving target that might someday meet my needs 
better.  Practicality beats purity, and all that.  :)