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

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to