[ZODB-Dev] zodb wants to import my module?

[Tim Peters]

[Chris Bainbridge]
> When I call get_transaction().commit() I sometimes get an ImportError
> from zodb:

More precisely, a ZEO client is reporting an exception raised on the ZEO
server, when an attempt at conflict resolution on the server failed, and the
attempt to raise ConflictError itself failed because the server wasn't able
to find the name of the class of the object for which conflict resolution
failed.

...
>   File
"/home/s9734229/root/lib/python2.3/site-packages/ZEO/ClientStorage.py",
> line 869, in _check_serials
>     raise s
> ImportError: No module named evolve
>
> Why is this?

As above <wink>.  You apparently don't have the code implementing your own
persistent classes installed on your ZEO server -- or perhaps you do, but
haven't set the Python path on the server so that the ZEO server can find
your persistent classes.

> Is it safe to ignore it?

Up to you.  ZEO was trying to give you a helpful message about a conflict
error.  As your later msg with the server traceback shows:

line 646, in store
    raise POSException.ConflictError(
  File
"/home/s9734229/root/lib/python2.3/site-packages/ZODB/POSException.py",
line 94, in __init__
    self.class_name = SimpleObjectReader().getClassName(data)
  File "/home/s9734229/root/lib/python2.3/site-packages/ZODB/serialize.py",
line 355, in getClassName
    klass = unpickler.load()
ImportError: No module named evolve

the server is trying to raise ConflictError, and the ConflictError
constructor is trying to determine the name of the object's class, by
loading just enough of the object pickle to get the name.  The
implementation of pickle does an import in this case (for a pickle GLOBAL
opcode), but the import failed.

I don't have a deep understanding of this part of the code (it's complicated
and obscure), and it's possible there's a bug.  But, offhand, it looks to me
like it would work fine if the ZEO server (as well as the ZEO client) had
your persistent class implementation code.

If it did, the transaction in question still would have failed, but by
raising ConflictError instead.