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
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
open. In my (zodb newbie's) mind this question translates to the
1. Is it possible associate a particular connection with a
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
Leo outline is open?
Yes. I would be worried about this approach too.
3. If multiple Leo outlines (and multiple connections) are open,
possible to define transactions that are specific to particular
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
starting with "NOTE: "... (the warning is just because the test
depends on the ZODB when all it technically needs to depend on is
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
an outline as above and then *closed* the connection, my prototype
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
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
if not v or not v._back:
File "C:\Python24\Lib\site-packages\ZODB\Connection.py", line 587, in
RuntimeError: Shouldn't load state for 0x60af when the connection
Here p is an instance of a Leo position, a short-lived object that
to vnodes and tnodes but is *not* itself persistent.
So is it possible for non-persistent objects to refer to persistent
Yes, while the connection is open. After that, you get errors, as
1. It appears that zodb does not update persistent objects properly
connection that created those objects is closed. I say this
because of the
traceback given above. Thus, I assume that *long-lasting*
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
be some way to **save one outline without saving them all**.
(or to revert one outline without reverting them all.) How do I
Again, in a fly-by opinion, I think saving use case needs in-memory
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?
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. ;-)
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org