[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