Re: [ZODB-Dev] tid error with ClientStorage cache in Zope 2.9.2

2006-04-28 Thread Chris Withers

Not sure if Jeremy still on this list so CCing...

Tim Peters wrote:

No, I don't. The internal docs/comments are inconsistent on this
point.  FileCache.settid() starts with

##
# Update our idea of the most recent tid.


Is this the most recently used or the most recently available?
(possible off-by-one error)


 This is stored in the
# instance, and also written out near the start of the cache file.  The
# new tid must be strictly greater than our current idea of the most
# recent tid.
def settid(self, tid):
...

and that comment matches the code you've seen failing. 


Indeed, but that code is just a check ;-)


 OTOH, this is
ClientCache.setLastTid():

##
# Set the last transaction seen by the cache.
# @param tid a transaction id
# @exception ValueError attempt to set a new tid less than the current tid
def setLastTid(self, tid):
self.fc.settid(tid)

The coments there say it's an error only if the new tid is  the
current tid, which is most reasonably taken to mean strictly less. 
That doesn't match the code wrt behavior when the tids are equal.


Hmmm...


The only other report of your traceback I'm aware of is part of this
confused bug report, in its Comment #4:

http://www.zope.org/Collectors/Zope/2038

That's also complaining about a new tid exactly equal to the
previous tid during verification.


Yeah, I saw that too, well, at least I'm not the only one ;-)


My best guess now is that the setLastTid() comments record the actual
intent, and that settid() is overly restrictive here in not allowing
equality.  But I don't understand/remember the details of cache
verification well enough to be sure.


In a perfect world, we could change it and see what tests fail.
I'm not that brave ;-)


The patch you found was me changing settid()'s code to match
settid()'s comments and the text of settid()'s error message.  I doubt
I noticed that those comments and the error message disagreed with
setLastTid()'s comments at the time, and expected Jeremy to complain
if he thought the change was wrong.  He still can, if he remembers the
details :-)


Well, I never saw these errors (which are from a specific check now 
based on a comment which may not have been correct as judged by my 
extremely limited understanding ;-) with Zope 2.7, which is the last 
version of Zope this instance ran on before 2.9...


Dunno if that helps at all :-S

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


[ZODB-Dev] Re: Changes in _p_changed behaviour between Zope 2.7 and 2.9

2006-04-28 Thread Chris Withers

Florent Guillaume wrote:

base._p_changed=0


Marks the object not changed, to allow ghostifying.


base._p_deactivate()


Ghostifies the object.


base.__setstate__(state)


Updates the object's dict directly. This really shouldn't be called on a
ghost object, I believe it's illegal but not checked. I'm not sure what
happens anyway.


Right, that's what I figured too, and I'm guessing ZODB now does the 
right thing, which breaks history copy because history copy has this 
bug ;-)



  base._p_activate()   # make sure we're not a ghost


Ah cool, never new that existed...


  base.__setstate__(state) # change the state
  base._p_changed = True   # marke object as dirty

The scrubbing is not necessary, it's done by the __setstate__ C
implementation of Persistent.


Okay, in that case we can loose everything funky before the __setstate__ 
call, right? How sure are you that __setstate__ will override 
everything? I see that Evan specifically added the code to do the 
scrubbing in revision 20478, sadly he didn't write tests or explain why 
it was necessary :-S



You don't need any transactions to at least test this sequence, only the
Persistent base class and a dummy connection can be involved.


Hmmm, this smells like deep fu of which I am not capable ;-)
Are there any examples of this?


To really test the history yes of course you'll need a full database. Many
tests do that.


Oh, do you know of any examples I can look at?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev