[Zope-DB] KeyError from Shared.DC.DA.DA

Dieter Maurer dieter at handshake.de
Mon Sep 25 13:27:22 EDT 2006


FAIRS, Dan, GBM wrote at 2006-9-25 08:58 +0100:
> ...
>Here's the salient part of the traceback:
>
>  File "/opt/intranet/cbfmnet/zope_home/Products/Membership/Member.py", line
>118, in _getDBValue
>    values = self._getDBValues(attributes=[attribute])
>  File "/opt/intranet/cbfmnet/zope_home/Products/Membership/Member.py", line
>96, in _getDBValues
>    , userid=login_elements[1]
>  File "/opt/intranet/cbfmnet/zope/lib/python/Shared/DC/ZRDB/DA.py", line
>453, in __call__
>    result=self._cached_result(DB__, (query, self.max_rows_))
>  File "/opt/intranet/cbfmnet/zope/lib/python/Shared/DC/ZRDB/DA.py", line
>375, in _cached_result
>    if int(cache[q][0]) == key:
>KeyError: ("execute dbo.EmployeeByNT 'DOMAIN', 'user'\n", 1000, '\nDBConnId:
>None')
>

The "DBConnId" is very strange ("None" rather than "DB_Connection").

Somehow, the "tcache" and "cache" variables are inconsistent.
I do not know however, how this can happen.

A theoretical possibility would be two different "tcache" entries
tcache[i1] = tcache[i2] = query.
Then "cache[query]" would be deleted for the first entry
and the second entry would result in a "KeyError".

However, such a case should be impossible...


You might want to use my "CCSQLMethods", which is more efficient
anyway (it uses a module level cache rather than a ZODB cache)
and definitely will avoid the problem above.

-- 
Dieter


More information about the Zope-DB mailing list