[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.
_______________________________________________
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
