An interesting way that SQLObject tries to get around this issue is to
have a module attribute on the database connection. So then the
original DatabaseException from the dbapi module is always at
conn.module.DatabaseException. But I'm not sure zope.rdb should try
that.
Indeed, very interesting idea, but I think for Retry and ConflictError
exceptions it is not a solution here.
In my case, with cxoracleda, there are some oracle errors like:
ORA-03113: End of file in the communication channel
that are 'killing' opened connection. That means this connection is still
opened but no longer useable. Thus it is necessary to close and reopen
this connection.
I've just changed cxoracleda to catch these specific exceptions
for example in cursor execute method. After catching exception database
connection is closed and Retry(...) exception raised.
This will cause that new connection will be created
when new (retried) request will start.
So far it is not possible to use this feature without defeating two bugs
in Zope3 that are subject of this thread. I had to monkey patch my zope3.
What does this mean? Are you suggesting implementing the full range of
dbapi errors in zope.rdb? Or letting the real errors propagate?
I mean to just let real errors propagate. Backends like
psycopg or cxoracleda are already dbapi aware
so errors they're raising (like ProgrammingError, InterfaceError)
are enough I think.
One problem with ripping out zope.rdb.interfaces.DatabaseException is
backwards compatibility and deprecation. I can't think of any sane way
to do that.
Right, so possibly first step should be to at last let Retry
and ConflictError errors propagate.
--
Maciej Wisniowski
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
