[Zope-dev] Coroner's toolkit for zope, or how to figure out what went wrong.

[Jim Fulton]

Romain Slootmaekers wrote:
> Jim Fulton wrote:
> 
>> Romain Slootmaekers wrote:
>>

...

> the object in question is created once, and there is no code to delete 
> it since in that application, it is of no use.
> The only thing that happens is that we add/moify/delete other object to
> that rootnode.

Right. In the problem database, did that object disappear, or did it's
contents disappear?


>> If you still have the data file with the lost data, it should be 
>> possible to
>> analyze it to figure out what went wrong. In particular, it would be 
>> helpful
>> to figure out just what transaction made the data go away to figure 
>> out what it
>> might have been doing.
> 
> 
> that was exactly the question I was asking in the first place :
> tools to browse the ZODB, to see where it broke.

It's not clear that the ZODB is broke. You didn't see any evidense
of a broken ZODB. No invalid object ids. No invalid transaction or
record data. The data in the database is not what you expect.

...

> But we found something else:
> 
> I included a script below that produces a stripped down analogy
> of our problem. (no zope needed, just ZODB, and you might wanna modify 
> the first line to get it working)
> 
> The script produces the following output:
> 
> 
> C:\zope\devel>bin\python.exe \temp\test.py
> <Foo instance at 008DCAC8> 0
> <Foo instance at 008E1280> 0
> Traceback (most recent call last):
>   File "\temp\test.py", line 68, in ?
>     get_transaction().commit()
>   File "C:\zope\devel\lib\python\ZODB\Transaction.py", line 234, in commit
>     j.commit(o,self)
>   File "C:\zope\devel\lib\python\ZODB\Connection.py", line 348, in commit
>     s=dbstore(oid,serial,p,version,transaction)
>   File "C:\zope\devel\lib\python\ZODB\FileStorage.py", line 665, in store
>     data=self.tryToResolveConflict(oid, oserial, serial, data)
>   File "C:\zope\devel\lib\python\ZODB\ConflictResolution.py", line 108, 
> in tryTo
> ResolveConflict
>     resolved=resolve(old, committed, newstate)
>   File "\temp\test.py", line 30, in _p_resolveConflict
>     print savedState['data'].getHello()
> AttributeError: PersistentReference instance has no attribute 'getHello'
> 
> 
> The question is: is this intended ZODB behaviour or not,

Yes, it is. When doing conflict resolution, you only get to use the state of
the object involved in the conflict. You don't get to see the state of persistent
subobjects. All sub-object references are converted to persistent references. This
is so, during conflict resolution, you can compare the object references for
equality.

 > and is there a work
> around ?

No.

Were you implementing application-level conflict resolution (_p_resolveConflict)
for any of your applicaton objects?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org