[ZODB-Dev] ZODB.tests.testZODB.checkResetCachesAPI definitely bad
These errors are *also* due to
ZODB.tests.testZODB.checkResetCachesAPI. The cache reset appears to
leave the Application object and/or transactions in a borked state.
All is well when I suppress checkResetCachesAPI:
$ python2.4 test.py -q -m '!^(ZEO|zope[.]app[.])' -t '!
checkResetCachesAPI' --all
Running unit tests:
Ran 7062 tests with 0 failures and 0 errors in 494.930 seconds.
Running
Testing.ZopeTestCase.zopedoctest.testLayerExtraction.TestLayer tests:
Set up
Testing.ZopeTestCase.zopedoctest.testLayerExtraction.TestLayer in
0.005 seconds.
Running:
..
Ran 2 tests with 0 failures and 0 errors in 0.025 seconds.
Tearing down left over layers:
Tear down
Testing.ZopeTestCase.zopedoctest.testLayerExtraction.TestLayer in
0.003 seconds.
Total: 7064 tests, 0 failures, 0 errors
Stefan
testInsideOutVirtualHosting
(webdav.tests.testPUT_factory.TestPUTFactory)
testNoVirtualHosting (webdav.tests.testPUT_factory.TestPUTFactory)
Error in test testNoVirtualHosting
(webdav.tests.testPUT_factory.TestPUTFactory)
Traceback (most recent call last):
File "/usr/lib/python2.4/unittest.py", line 251, in run
self.setUp()
File "/home/buildbot/slave-zope.org/zc-buildbot--Linux--Zope---
branches---2.9--2.4/build/lib/python/webdav/tests/
testPUT_factory.py", line 22, in setUp
self.app.manage_addFolder('folder', '')
File "/home/buildbot/slave-zope.org/zc-buildbot--Linux--Zope---
branches---2.9--2.4/build/lib/python/OFS/Folder.py", line 49, in
manage_addFolder
self._setObject(id, ob)
File "/home/buildbot/slave-zope.org/zc-buildbot--Linux--Zope---
branches---2.9--2.4/build/lib/python/OFS/ObjectManager.py", line 300,
in _setObject
v = self._checkId(id)
File "/home/buildbot/slave-zope.org/zc-buildbot--Linux--Zope---
branches---2.9--2.4/build/lib/python/OFS/ObjectManager.py", line 95,
in checkValidId
raise BadRequest, (
BadRequest: The id "folder" is invalid - it is already in use.
On 12. Sep 2006, at 02:52, [EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope branches 2.9 2.4
Linux zc-buildbot.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 7595
Blamelist: adamg,ctheune,flindner,flox,jim,tseaver
BUILD FAILED: failed test
sincerely,
-The Buildbot
--
It doesn't necessarily do it in chronological order,
though. --Douglas Adams
___
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
[ZODB-Dev] Newbie questions re persistent objects and connections: [Was: can Leo...]
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 :-) All you really need to know about Leo is an editor that represents programs as outlines. For full details, see: http://webpages.charter.net/edreamleo/front.html Several of Leo's users have suggested that Leo could use the zodb instead of reading and writing files. I hope a zodb guru can help me determine whether this project is feasible. I have spent several days writing simple prototype code. I'll try to make this post as short as possible, but some background is needed. I'll attempt to make my assumptions explicit so they can be corrected as needed... The idea is to represent a Leo outline as an entry in the zodb. To write the data Leo would do: connection = self.db.open() root = connection.root() root[fileName] = v get_transaction().commit() v is the root of a tree of Leo's vnodes and tnodes. (vnodes and tnodes contain all of Leo's persistent data, and vnodes and tnode both derive from ZODB.Persistence.Persistent.) Similarly, to open a new Leo outline: v = root.get(fileName) c2 = c.new() # Create a new outline, whose 'commander' is c2. c2.setRootVnode(v) # Tell the commander the root of the outline is v. 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? 2. Is it possible to **leave a connection open** for as long as a particular Leo outline is open? 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? 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? 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? 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? Thanks for your help. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html ___ 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
Re: [ZODB-Dev] Newbie questions re persistent objects and connections: [Was: can Leo...]
Edward K. Ream wrote: This is a repost of my original: Can Leo use zodb as a file system. Yes (s/file system/persistent store/). Start here: http://www.zope.org/Wikis/ZODB/guide/zodb.html This might also be helpful, although potentially slightly out of date: http://www.zope.org/Members/adytumsolutions/HowToLoveZODB_PartI -- Benji York Senior Software Engineer Zope Corporation ___ 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
Re: [ZODB-Dev] Newbie questions re persistent objects and connections: [Was: can Leo...]
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
[ZODB-Dev] re: re: Newbie questions re persistent objects and connections: [Was: can Leo...]
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. Many thanks for this reply. Using copies of zodb objects should be straightforward. Having only one short-lived connection open at a time would probably keep things simplest. I think the reverting use case needs a mechanism other than ZODB undo. If at most one connection is ever open, a Leo-revert is just a pull from the zodb, something like: # Exception-handling omitted... connection = db.open() v = connection.root().get(fileName) v2 = c.zodbTreeToLeoTree(v) get_transaction().commit() connection.close() c.setRootVnode(v2) c.redraw() Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html ___ 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
[ZODB-Dev] Problem Storing Infinity
I'm having a problem storing infinity. The following code reproduces
the problem on w2k:
from ZODB import FileStorage, DB
from persistent import Persistent
from persistent.mapping import PersistentMapping as dict
import transaction
storage = FileStorage.FileStorage('zodb.db')
db = DB(storage)
conn = db.open()
root = conn.root()
try:
root['data'] = 1e
finally:
transaction.commit()
conn.close()
db.close()
storage.close()
Traceback (most recent call last):
File "test/test_zodb.py", line 14, in ?
transaction.commit()
File "C:\Program
Files\Python24\Lib\site-packages\transaction\_manager.py", line 96, in
commit
return self.get().commit(sub, deprecation_wng=False)
File "C:\Program
Files\Python24\Lib\site-packages\transaction\_transaction.py", line
380, in commi
t
self._saveCommitishError() # This raises!
File "C:\Program
Files\Python24\Lib\site-packages\transaction\_transaction.py", line
378, in commi
t
self._commitResources()
File "C:\Program
Files\Python24\Lib\site-packages\transaction\_transaction.py", line
433, in _comm
itResources
rm.commit(self)
File "C:\Program
Files\Python24\lib\site-packages\ZODB\Connection.py", line 484, in
commit
self._commit(transaction)
File "C:\Program
Files\Python24\lib\site-packages\ZODB\Connection.py", line 526, in
_commit
self._store_objects(ObjectWriter(obj), transaction)
File "C:\Program
Files\Python24\lib\site-packages\ZODB\Connection.py", line 553, in
_store_objects
p = writer.serialize(obj) # This calls __getstate__ of obj
File "C:\Program
Files\Python24\Lib\site-packages\ZODB\serialize.py", line 407, in
serialize
return self._dump(meta, obj.__getstate__())
File "C:\Program
Files\Python24\Lib\site-packages\ZODB\serialize.py", line 416, in
_dump
self._p.dump(state)
SystemError: frexp() result out of range
___
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
Re: [ZODB-Dev] Problem Storing Infinity
That's interesting. It appears that pickle protocol 2 chokes on inf. ->> from cPickle import dumps ->> dumps(1e9) 'Finf\n.' ->> dumps(1e9, 2) Traceback (most recent call last): File "", line 2, in ? SystemError: frexp() result out of range ->> ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
On Sep 12, 2006, at 11:55 AM, David Binger wrote: That's interesting. It appears that pickle protocol 2 chokes on inf. ->> from cPickle import dumps ->> dumps(1e9) 'Finf\n.' ->> dumps(1e9, 2) Traceback (most recent call last): File "", line 2, in ? SystemError: frexp() result out of range ->> Yeah, especially because I didn't realize we were using protocol 2 yet. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
Chris S wrote at 2006-9-12 11:38 -0400: > ... >return self._dump(meta, obj.__getstate__()) > File "C:\Program >Files\Python24\Lib\site-packages\ZODB\serialize.py", line 416, in >_dump >self._p.dump(state) >SystemError: frexp() result out of range Tim (Peters) explained several problems with "improper" floating point numbers (such as infinity and NANs) on "comp.lang.python"). Apparently, such numbers are handled differently by the C runtime libraries on different platform. What you see is almost surely such a C library issue. -- Dieter ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
[Chris S] I'm having a problem storing infinity. The following code reproduces the problem on w2k: Purely a Python issue. Nothing about the behavior of infinities, NaNs or signed zeroes is defined in Python before (the not yet released) 2.5. In 2.5, marshal and pickle (but only with protocol >= 1) can at least pack and unpack them reliably across most IEEE-754 boxes. ZODB will inherit that when used with Python 2.5. Before then, sorry, but no chance. ... try: root['data'] = 1e Also undefined what that literal might mean. This is all platform-dependent accident, essentially because Python inherits most of its knowledge of floats from the platform C implementation, and nothing about IEEE-754 special values is defined in the C89 standard -- different C implementations slobber all over the map in what they do with such things. ... self._p.dump(state) SystemError: frexp() result out of range Yup, that's one of the platform-dependent accidents you might see. Reflects that this platform C's libm's frexp() implementation happens to be unhappy with infinities. Some are, some aren't. [David Binger] That's interesting. It appears that pickle protocol 2 chokes on inf. As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. [Jim Fulton] Yeah, especially because I didn't realize we were using protocol 2 yet. Strongly doubt that ZODB uses protocol 2 anywhere yet. ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
On Sep 12, 2006, at 2:11 PM, Tim Peters wrote: [David Binger] That's interesting. It appears that pickle protocol 2 chokes on inf. As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. I was thinking that the default protocol is 1, but I see now that the default is 0. 2.4.2 on OS X can pickle infinity using protocol 0, but attempts to pickle infinity using protocols 1 or 2 raise a SystemError. Pickling infinity works fine, just as you say, in 2.5, using any of the protocols. Thanks for the explanation. ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
[David Binger] That's interesting. It appears that pickle protocol 2 chokes on inf. [Tim Peters] As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. [David] I was thinking that the default protocol is 1, but I see now that the default is 0. Strange, eh? Since only protocol 0 existed at first, I suppose this was a nod to backward compatibility. 2.4.2 on OS X can pickle infinity using protocol 0, but attempts to pickle infinity using protocols 1 or 2 raise a SystemError. All of which are platform-dependent accidents. Pickling infinity works fine, just as you say, in 2.5, using any of the protocols. Well, I meant what I said ;-): In 2.5, marshal and pickle (but only with protocol >= 1) can at least pack and unpack them reliably across most IEEE-754 boxes. It's /still/ an accident that protocol 0 worked for you under 2.5. WinTel is the major example of a 754 box where protocol 0 still doesn't work under 2.5, and probably never will (Microsoft's C implementation can't read the strings it produces for infinities or NaNs, which pretty much dooms "text mode" pickles forever in those cases): Python 2.6a0 (trunk:51860, Sep 11 2006, 15:23:15) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. import cPickle p = cPickle.dumps(1e300 * 1e300) p 'F1.#INF\n.' cPickle.loads(p) Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float p = cPickle.dumps(1e300 * 1e300, 1) cPickle.loads(p) 1.#INF So protocol 0 still fails, while protocol 1 (or higher) works, and all of them fail on WinTel before 2.5. Thanks for the explanation. Hey, it's always my pleasure to spread fear :-) ___ 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
Re: [ZODB-Dev] Problem Storing Infinity
On Sep 12, 2006, at 3:07 PM, Tim Peters wrote: [David Binger] That's interesting. It appears that pickle protocol 2 chokes on inf. [Tim Peters] As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. [David] I was thinking that the default protocol is 1, but I see now that the default is 0. Strange, eh? Since only protocol 0 existed at first, I suppose this was a nod to backward compatibility. Plus version 0 pickles are more readable. :) Honestly. (Some time I really need to promote xmlpickle more. It's very nice for looking at pickles. Unfortunately, it doesn't understand protocol 2 yet.) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
[ZODB-Dev] Re: Problem Storing Infinity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > > On Sep 12, 2006, at 3:07 PM, Tim Peters wrote: > >> [David Binger] > That's interesting. > It appears that pickle protocol 2 chokes on inf. >> >> [Tim Peters] As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. >> >> [David] >>> I was thinking that the default protocol is 1, but I see >>> now that the default is 0. >> >> Strange, eh? Since only protocol 0 existed at first, I suppose this >> was a nod to backward compatibility. > > Plus version 0 pickles are more readable. :) Honestly. The verbosity comes at a non-trival price in high-write scenarios. Being able to compress away the class name of 'OOBucket', for instance, could reduce the amount of crap slung throgh the network by a lot. > (Some time I really need to promote xmlpickle more. It's very nice for > looking at pickles. Unfortunately, it doesn't understand protocol 2 yet.) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBxu3+gerLs4ltQ4RAv1aAKCyphLd7f9aOns81hGa0vJGEEDOVgCdEHiB 00ihZl8yJf2q+2CpZ3gBnNg= =wWjx -END PGP SIGNATURE- ___ 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
[ZODB-Dev] Re: Problem Storing Infinity
On Sep 12, 2006, at 4:42 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Sep 12, 2006, at 3:07 PM, Tim Peters wrote: [David Binger] That's interesting. It appears that pickle protocol 2 chokes on inf. [Tim Peters] As above. BTW, why protocol 2 specifically? Protocols 1 and 2 treat floats the same way. [David] I was thinking that the default protocol is 1, but I see now that the default is 0. Strange, eh? Since only protocol 0 existed at first, I suppose this was a nod to backward compatibility. Plus version 0 pickles are more readable. :) Honestly. The verbosity comes at a non-trival price in high-write scenarios. Sure. That's why we invented protocol 1 as part of the cPickle effort and why we use it in ZODB. Being able to compress away the class name of 'OOBucket', for instance, could reduce the amount of crap slung throgh the network by a lot. Yeah, which protocol 2 would let us do. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
