[ZODB-Dev] Setting _p_changed on a ghost

[Tim Peters]

[Tim Peters]
>> ...
>> I would like to make it an error (raise a ValueError exception) to
>> attempt to set obj._p_changed to a true value when obj is a ghost.  Does
>> anyone object?

[Dieter Maurer]
> I came along an argument against this change:
>
>   Assume, you have a persistent object "o" with a mutable
>   non persistent attribute "a".
>
>   One of the idioms for changing "a" looks like:
>
>       ... modify "o.a" ...
>       o._p_changed = True
>
>   However, as Shane pointed out, this may cause ZODB inconsistencies:
>
>       When "... modify "o.a" ..." raises an exception,
>       then "a" may or may not already have been modified.
>       Such changes may be committed in a future transaction
>       (not the current one, as this is aborted).
>
>   Therefore, he proposed to change the idiom to:
>
>       o._p_changed = True
>       ... modify "o.a" ...
>
>   Now, the persistence subsystem (hopefully) already knows the "o" is
>   changed and invalidates it on abort. The inconsistency cannot occur.
>
>   Of course, raising an exception when "o" happens to be
>   a "ghost", would not be appropriate for this idiom -- neither
>   is the current behaviour to just ignore the assignment
>   to "_p_changed".

It's a strong argument, and I've implemented the better change on ZODB trunk
(well, not quite yet -- final test run still in progress):  in ZODB 3.6,
setting obj._p_changed to a true value, when obj is a ghost, activates
(unghostifies) obj and changes obj's state (from the ghost state to the
changed state).  Part of putting obj in the changed state is telling obj's
data manager that it _has_ changed, so your

    the persistence subsystem (hopefully) already knows the "o" is
    changed

will be true in the scenario you sketched.

Note that I don't plan to backport this to ZODBs earlier than 3.6.