[ZODB-Dev] Help: ZODB undo problem

[Mike C. Fletcher]

Updates:
	reset is definitely there in my copy of Zope3's ZODB (downloaded and 
re-built today).  I'm thinking I wasn't clear in the problem statement 
that it's Zope3, not Zope2 ZODB I'm using.  Leaving out any of the three 
statements (reset, synch and _resetCache) winds up creating the 
ConflictErrors (even with the latest version of my code).  Is there a 
public method that invalidates all objects in the cache?

	I tried the latest version from CVS, no help there.

	I wound up having to use not weak-reference objects, but "indirect 
reference" objects (i.e. I re-access the object from the connection for 
every single access to the object).  Weak references would hang around 
if there happened to be a reference from something else to the object 
that hadn't been gc'd yet (which happens a lot in my GUI system).

	I use a simple "refresh" message from dispatcher.py to synch all windows 
when there's any change to the dbase, seems to work properly now 
(there's a memory-access error that has shown up during testing, but I 
don't think it's related to Zope (seems to be a problem with 
de-allocation of wxPython command events and colour objects)).

With thanks for all your help,
Mike

Shane Hathaway wrote:
> Mike C. Fletcher wrote:
> 
>> Thanks Shane and Christian,
...
> Hmm.  You should look at several things:
> 
> 1) What is reset()?  My up-to-date CVS checkout of ZODB has no reset() 
> method anywhere.  Are you sure this isn't throwing an AttributeError, 
> preventing sync() from ever getting called?
> 
> 2) I'm quite sure you don't want to call _resetCache() anywhere in your 
> code, since that partially disconnects your objects from the database, 
> and you can expect broken behavior once that happens.  Just trust me, 
> don't do it.  I'd do a grep in your code for _resetCache(), and if you 
> find any instances anywhere, zap them. :-)  _resetCache() is not part of 
> the public API.
> 
> 3) Is your copy of ZODB up to date?  The trunk ZEO had a bug last week 
> that prevented invalidations from propagating; maybe you just need to 
> "cvs up".
...