[TransWarp] Strange EntityDM behavior

[Phillip J. Eby]

At 10:23 PM 10/6/03 -0700, John Landahl wrote:
>I'm seeing some strange behavior using EntityDM.  I create a new object,
>assign some values, and commit.  When I try to reload that same object
>(having saved its ID), change a field, and commit, it seems the changes don't
>get saved.  After putting a debug print in my DM's _save method, it appears
>that _save isn't getting called as I would expect.
>
>Attached is a program which isolates and demonstrates the problem.  Even more
>strangely, in this program it seems that _save is never called at all!

It's a PEAK bug.  I've just checked in a fix.

What happened is that I made some changes to peak.storage.data_managers to 
support the latest ZODB4, which has a different API for deactivating an 
object.  Previously, 'del ob._p_changed' would force deactivation of an 
object.  In newer ZODB4 versions, 'del ob._p_changed' doesn't work, you're 
supposed to use 'ob._p_deactivate(force=1)'.  But, I goofed in transcribing 
this, and just used 'ob._p_deactivate()'.  But, this only works for objects 
that aren't changed.

Anyway, the result was that, once you changed an object, it stayed in 
memory in a "changed" state and would never be re-registered with the DM as 
a changed object.  Thus, it was never re-saved.


>The output I get for the program (executing via "PYTHONPATH=. peak
>import:test.App") is this:
>
>   === _new
>   === _items
>   Initial value: "" (should be blank)
>   After first update: "update1" (should be "update1")
>   After first update: "update2" (should be "update2")
>   (1, '', '')
>
>When I'd expect something more like this:
>
>   === _new
>   === _items
>   Initial value: "" (should be blank)
>   === _save
>   After first update: "update1" (should be "update1")
>   === _load
>   === stateFromRow
>   === _items
>   After first update: "update2" (should be "update2")
>   === _save
>   (1, 'update3', 'description')
>
>Am I missing something?

The actual output is a bit different, but it's substantially as you 
expect.  There is, however, a minor bug in your script: each TableDM opens 
its own database connection, instead of sharing the one provided by 
'App'.  Instead of binding to 'DATABASE' they should be using a key that 
you supply to 'offerAs', such as the PropertyName you are currently supplying.