Re: Re: trellis.Set.discard

On Sun, Oct 12, 2008 at 06:45, Phillip J. Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> wrote:
> At 02:13 AM 10/12/2008 +0300, Sergey Schetinin wrote:
>>
>> >> There's more. For task, maintain rule runs twice, then undo run for
>> >> both times. So it not run-undo-run or even run-undo-run-undo it's
>> >> run-run-undo-undo. For @atomically it also runs twice, but without
>> >> undo. How the same rule manages to run twice without undo?
>> >
>> > Because the first run is inside type(CV).__call__ - it's an initializer
>> > that's supposed to be treated as if its run happened in a *previous*
>> > recalc
>> > - and it should never be undone.
>>
>> Oh, I see! This indeed seem like the right thing to do, but if the
>> initialization sets some discrete cells shouldn't they reset by the
>> time this call returns?
>
> I think you're almost right about this.  I say "almost" because you can pass
> data into this initialization; so should that count as a write?  I'm rather
> torn because the main use case for making the initialization special is to
> deal with Service objects, whose instantiation cannot be undone.  So,
> undoing their setup seems also wrong.
>
>> This would also solve the futures issue, I
>> believe.
>
> Yes and no.  I think it could still be made to mess things up.  I don't
> think the initialization aspect is crucial to setting up a futures-based
> retry cause the partial rollback of a rule.
>


It seems to me that we can think of new cells as just cells we
introduce to our cell network, they could be coming from anywhere,
from persisted storage or even alternate universe, it doesn't matter.
This way we don't need to differentiate between cells we've just
created and some cells we've got from somewhere else. If this is
correct, then we don't need to treat initialization as a write, but
for this to work these new cells need to be exactly in the same state
as if they weren't touched in this transaction, which means discrete
values should be reset, there should be no scheduled calls for any of
them and no related undo / commit actions pending. For futures, this
means they shouldn't have any savepoints saved. For this test case
Set._data wouldn't be scheduled and .to_add would be untouched. This
would fix this case, because if we create CV in a different
transaction it works fine. I too can think of ways to break things
with savepoints in futures, but it would be a bit harder.

Also, if we pass cell objects to Component.__init__, I think it still
can work as long as these passed cells aren't changed. In fact during
the creation of these new cells they shouldn't change *anything* else
in our existing cells. In fact, it would be better to split the
initialization into two stages, fisrt is when the new cells are
created (possibly with passed data) and run in isolation, this can't
and shouldn't need to rollback. Second is when these cells are
introduced to our transaction, now the can write to existing cells,
but this is logged for undo. Without this, it seems to me that Trellis
would be broken in subtle ways all the time.





-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter