[PEAK] Trellis on_commit and Performers

[Phillip J. Eby]

At 09:27 AM 10/3/2008 +0300, Sergey Schetinin wrote:
>Performers don't seem to notice changes that are made in on_commit
>callbacks. In this sample the use of on_commit doesn't make sense, but
>generally it can be useful. Anyway if this is by design, it would be
>great if cases like this were detected and raised an exception.

It's not exactly "by design", but this line in the README should be a clue:

"""* It's a bad idea to use ``on_commit()`` for user-level operations"""

;-)

The ``on_commit`` function is part of the low-level STM 
infrastructure that the Trellis cell system runs on top of.  You 
therefore can't expect any sort of inter-cell consistency within 
callbacks, as they are used to do cleanup of individual cells in ways 
that don't interact with each other.  So, don't use on_commit unless 
that's the sort of thing you're doing.


>from peak.events.trellis import *
>
>class Watch(Component):
>     list = attr()
>     @perform
>     def watch_count(self):
>         print len(self.list)
>
>
>l = List()
>lw = Watch(list=l)
>atomically(on_commit, l.append, 1)
>
>
>This prints just []
>
>
>I also wonder if I'm trying to make Trellis do something it can't.
>What I'm trying to do is to collect all the data required for certain
>operation with side-effects and perform it in on_commit. That
>operation also changes some Trellis cells which then should trigger a
>set of performers that would modify the newly created
>(non-trellis-managed) object.
>
>To work around this, I changed the code to schedule the call by other
>means than on_commit, so the second round of changes happens in a new
>transaction, but I wonder what's the intended way to accomplish this?

Why can't you just use a maintenance rule that depends on the 
accumulated data, and let the trellis arrange things in the right 
order?  I don't see why you need two transactions here.