[Zope] calling 'manage_copyObjects' and 'manage_pasteObjects' in a loop

[Jean Jordaan]

Hi all

This is just a inconclusive report, in case someone else has seen
something similar.

While moving from racks to remoteracks, I used this code:

  for dm in datamanagers:
    specialist = specialists[dm]
    rack = specialist.defaultRack
    remote_rack = specialist.Rack

    ids = rack.objectIds()

    copy_cookie = rack.manage_copyObjects(ids)
    remote_rack.manage_pasteObjects(copy_cookie)

Just after running it, I got a bunch of these errors in my log,
when trying to view the remoteracks:

 ------
 2002-05-14T14:56:50 ERROR(200) ZODB Couldn't load state for
'\x00\x00\x00\x00\x0
0\x04g['
 Traceback (innermost last):
  File /usr/local/zope/2-4-3/lib/python/ZODB/Connection.py, line 519, in
setstat
e
  File /usr/local/zope/2-4-3_for_diepdink/lib/python/ZODB/FileStorage.py,
line 5
88, in load
    (Object: /home/httpd/zope-instances/jean/creme.dev/var/Data.fs)
  File /usr/local/zope/2-4-3_for_diepdink/lib/python/ZODB/FileStorage.py,
line 5
64, in _load
    (Object: /home/httpd/zope-instances/jean/creme.dev/var/Data.fs)
 KeyError: ^@^@^@^@^@^Dg[

I couldn't undo the transaction (since I'd inadvertently deleted some
of the copied objects by refreshing a view where I'd previously deleted
them). I recovered by truncating Data.fs to before the last big
transaction (i.e. transaction which touched a lot of objects, as shown
by 'fsrecover.py -v2' -- it would be nice if -v was even more verbose
about the transactions.)

I repeated the copy script just now, and it worked without a hitch.
Does anyone know any way the above snippet could trigger those
KeyErrors?

--
Jean Jordaan
Upfront Systems                         http://www.upfrontsystems.co.za