[ZODB-Dev] Newbie questions re persistent objects and connections: [Was: can Leo...]

[Gary Poster]

On Sep 12, 2006, at 8:24 AM, Edward K. Ream wrote:

> This is a repost of my original: Can Leo use zodb as a file system.
> Both the title of the thread and the botched formatting may have  
> put people
> off, so let's try again :-)

I know Leo. :-)  It's cool.

Benji's email is the right reply.  I'll try to give you a few  
pointers to your specific questions.

In my reply, I warn you that I'll say things like "I would be worried  
about this approach" and "hypothetically" and other worrisome  
things.  My intent is to convey that the small amount of time I have  
to spend on this email just gives me time for gut feelings, and I  
haven't written an app like Leo or used the ZODB outside of message  
based systems, so I don't want to say "bad idea" outright.  Sorry for  
the wishy-washy replies.

...

> I want to know if this scheme can be used if there are multiple Leo  
> outlines
> open. In my (zodb newbie's) mind this question translates to the  
> following
> zodb-specific questions:
>
> 1. Is it possible associate a particular connection with a  
> particular Leo
> outline?

Only in application logic.  I would be worried about this approach.

>
> 2. Is it possible to **leave a connection open** for as long as a  
> particular
> Leo outline is open?

Yes.  I would be worried about this approach too.

> 3. If multiple Leo outlines  (and multiple connections) are open,  
> is it
> possible to define transactions that are specific to particular  
> connection?
> In particular, does something like connection.commit() exist, and  
> if so, how
> are connection-specific transactions defined?

Give each connection its own transaction manager.  For instance, see  
this file:

http://svn.zope.org/zc.queue/trunk/src/zc/queue/queue.txt? 
rev=67933&view=auto

starting with "NOTE: "... (the warning is just because the test  
depends on the ZODB when all it technically needs to depend on is  
persistence).

Doing this can be tricky, and as per usual, I would be worried about  
this approach. ;-)

> The reason I ask these particular questions is this:  If my  
> prototype opened
> an outline as above and then *closed* the connection, my prototype  
> threw
> this exception soon after I started to use the outline:
>
> Traceback (most recent call last):
>
>  File "C:\prog\tigris-cvs\leo\src\leoGlobals.py", line 5010, in  
> getScript
>    elif p == c.currentPosition():
>  File "C:\prog\tigris-cvs\leo\src\leoNodes.py", line 1370, in __cmp__
>    if p1.childIndex() != p2.childIndex():
>  File "C:\prog\tigris-cvs\leo\src\leoNodes.py", line 1580, in  
> childIndex
>    if not v or not v._back:
>  File "C:\Python24\Lib\site-packages\ZODB\Connection.py", line 587, in
> setstate
>    raise RuntimeError(msg)
> RuntimeError: Shouldn't load state for 0x60af when the connection  
> is closed
>
> Here p is an instance of a Leo position, a short-lived object that  
> *refers*
> to vnodes and tnodes but is *not* itself persistent.
>
> So is it possible for non-persistent objects to refer to persistent  
> objects?

Yes, while the connection is open.  After that, you get errors, as  
demonstrated above.

> Summary
>
> 1. It appears that zodb does not update persistent objects properly  
> when the
> connection that created those objects is closed.  I say this  
> because of the
> traceback given above.  Thus, I assume that *long-lasting*  
> connections are
> required to support persistent objects.  Is this assumption correct?

No.  That's one approach, and is hypothetically reasonable.

Another approach would be to have in-memory copies of the objects in  
the zodb (they could even be the same class, just without a database  
connection).  Saving the file pushes the copy's data to the ZODB and  
commits a transaction.  This would work with a single long running  
connection or with short connections, opened just for save and load.   
That would be my first take on ZODB integration with Leo, FWIW.

> 2. With multiple Leo outlines connected to multiple connections  
> there must
> be some way to **save one outline without saving them all**.
> (or to revert one outline without reverting them all.)  How do I  
> define
> outline-specific transactions?

Again, in a fly-by opinion, I think saving use case needs in-memory  
copies.

I think the reverting use case needs a mechanism other than ZODB  
undo.  If I had worlds enough and time, I would try to help you use  
zc.vault, which I think would be ideal for this purpose.  As it is,  
I'll just point you to this rather ovewhelming document and run  
away. :-(  http://svn.zope.org/zc.vault/trunk/src/zc/vault/README.txt? 
rev=69750&view=auto

I hope this helps a bit.  The main point of the email is to let you  
know that people care, and want to help out as possible. ;-)

Gary