[PEAK] Re: trellis.Set.discard

[Phillip J. Eby]

At 04:52 PM 10/21/2008 +0300, Sergey Schetinin wrote:
> > Hi Sergey; I've been out of town a few days, and won't likely have time for
> > in-depth analysis this week either.  But I can tell you that restricting
> > futures to single-rule access is a no-go; the whole point of futures was to
> > allow multiple rules to touch the same data structure, allowing
> > non-deterministic merge at the inter-rule level.
> >
> > In other words, data structures do allow for "order" to be between rules,
> > but it is a serializable history.
>
>I understand, but can this intention be fulfilled without breaking
>some fundamental requirements? Current solution with saved savepoints
>can't work because even if it's changed to roll back to the beginning
>of the rule where future was first accessed, it would still be
>incompatible with tasks / top-level modifiers. So there needs to be a
>way to do partial rollback, which requires making a copy each time
>it's accessed by a different rule.

Yep, I just had the same idea this morning, and I think it's a *lot* 
simpler to implement correctly than deterministic merge.  We could 
allow todo cells to have a copy function, that defaults to 
copy.copy().  When a new rule reads the cell's future, it would 
change_attr to a copy and then return it, and we wouldn't need all 
the savepoint junk.  (Because rules are rolled back in their entirety 
for redo.)


>And if we do that it's not a long way from what I propose. Also,
>making the merge deterministic would allow us to add a number of
>useful properties. For example, currently if one rule adds an item to
>the Set and then some other discards it, the outcome depends on the
>order they run. But if we choose to merge changes ourselves we can
>make sure that such conflicting changes would be detected (no matter
>what order they run in), but at the same time, adding then removing an
>item wouldn't be considered a conflict as long as it's done in the
>same rule.

The problem with this is that error detection is deferred, which 
makes debugging even harder than it already is.


>Actually, it seems to me that rules should see the data structures in
>the way they entered the transaction, so if some rule adds a new item
>to the set, no other rule should be able to remove it before @todo
>cell gets the value (Set.added for this example).
>
>Anyway, ISTM that .futures the way they are don't fit Trellis model very well.

Futures are just a way to simplify creating trellis-ized data 
structures, so that you don't have to undo-log everything.  Replacing 
this with a merge requirement rather defeats the point; if you want 
things to happen deterministically, you can always use separate data 
structures and a rule that combines them in a specific order.


> > The ability to have a side-transaction is a good idea, though.  (Really a
> > "back transaction", since it is sort of happening in the past.)  I haven't
> > thought a lot about the isolation parameters, though.
> >
> > Prototyping certainly would be helpful.
>
>I don't think I will have anything interesting to show before next
>week, but so far I'm using this monkeypatch:

I still need to read back to your original notes on side transactions 
and why they're important, apart from the futures issue.  I think 
that snapshot-copying futures when accessed by a new rule will 
prevent futures from triggering rollbacks of the type you originally 
reported, so I'm not clear at the moment on what else needs to be 
done with side transactions.