Tim Peters wrote at 2004-5-31 20:49 -0400:
> ...
>Perhaps we could say that if it
>returns True, then the object should be considered to be in the changed
>state rather than in the uptodate state.
+1
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTE
"Tim Peters" <[EMAIL PROTECTED]> writes:
> That adds something to the BTree that is bound to an attribute of articleDb,
> but still doesn't set _p_changed on articleDb (mutating the BTree does not
> mutate the object containing the BTree). So far as the *database* is
> concerned, there's still no
[Syver Enstad]
> I was aware that __setstate__ doesn't allow me to commit my changes after
> only loading the object into memory (__setstate__ is called). I may have
> explained myself unclearly (not a native english speaker/writer),
I don't think that matters much: English instead of code is alw
"Tim Peters" <[EMAIL PROTECTED]> writes:
> [Syver Enstad, wants to switch an attribute of a Persitent subclass
> From PersistentList to an IOBTree]
>
> [Tim, guessing]
> > Quick guess (untested, untried, ...
> ...
> > Perhaps shuffling the code around would work, a la:
> >
> > Persistent.__s
[Tim Peters]
>> ...
>> On ZODB head, Jeremy also documented that __setstate__ can't affect the
>> persistent state (in persistent/interfaces.py's IPersistent). Whether
>> this is deliberate design, or a consequence of the current
>> implementation, I can't say.
[Dieter Maurer]
> A potential probl
Tim Peters wrote at 2004-5-30 14:49 -0400:
>[Dieter Maurer]
>> I think, this is a ZODB buglet:
>>
>> It should set "_p_changed = 0" before it calls "__setstate__"
>> and not afterwards...
>
>I don't know; Jim (or Jeremy) may know the reasoning here, but I don't.
>
>Activation currently sets the
[Dieter Maurer]
> I think, this is a ZODB buglet:
>
> It should set "_p_changed = 0" before it calls "__setstate__"
> and not afterwards...
I don't know; Jim (or Jeremy) may know the reasoning here, but I don't.
Activation currently sets the state to changed *before* calling __setstate__
too.
Tim Peters wrote at 2004-5-28 14:51 -0400:
> ...
>This appears to be one of those "severely underdocumented" minefields. The
>best older thread I found is here:
>
>http://mail.zope.org/pipermail/zodb-dev/2002-March/002442.html
>
>but it doesn't actually spell out something "that works" in the
Syver Enstad wrote at 2004-5-28 12:41 +0200:
>I have a Persistent derived class where I want to upgrade from using a
>PersistentList to a BTrees.IOBTree.IOBTree.
>
>_articleList is the old Persistent list
>_oidsToArticles is the new IOBTree.
>
>def __setstate__(self, state):
>articleLis
FWIW, __setstate__ for Zope objects has typically been used as a
"one-way" kind of backwards compatibility mechanism (where the object's
database state remains unmodified, but the in-memory state is changed)
not only for the reasons that Tim just explained, but also because
changing the persistent
[Syver Enstad, wants to switch an attribute of a Persitent subclass
From PersistentList to an IOBTree]
[Tim, guessing]
> Quick guess (untested, untried, ...
...
> Perhaps shuffling the code around would work, a la:
>
> Persistent.__setstate__(self, state)
> articleList = state.get('_artic
[Syver Enstad]
> I have a Persistent derived class where I want to upgrade from using a
> PersistentList to a BTrees.IOBTree.IOBTree.
>
> _articleList is the old Persistent list
> _oidsToArticles is the new IOBTree.
>
> def __setstate__(self, state):
> articleList = state.get('_articleL
12 matches
Mail list logo
