ruote tmp/log_2011-06-14.html

2011-06-14 23:36:56 utc ian-howcast jmettraux: do you have some time to chat about some work I'm trying to do with re_apply?
2011-06-14 23:37:15 utc jmettraux hello, https://gist.github.com/1026185 ?
2011-06-14 23:37:33 utc ian-howcast lol, you found that fast
2011-06-14 23:37:53 utc jmettraux yes, let's chat
2011-06-14 23:37:56 utc ian-howcast thanks
2011-06-14 23:38:05 utc ian-howcast so, this effort started as:
2011-06-14 23:38:17 utc ian-howcast take a long running process and "upgrade" its definition
2011-06-14 23:38:36 utc ian-howcast works pretty well by just reapplying the new tree to the root expression
2011-06-14 23:38:58 utc jmettraux whoah, that's radical
2011-06-14 23:39:12 utc ian-howcast eg. RuoteGardener.new(status).update_tree! new_pdef
2011-06-14 23:39:43 utc ian-howcast the next thing was to be able to map workitems from one pdef to the next
2011-06-14 23:39:55 utc ian-howcast eg.
2011-06-14 23:39:56 utc ian-howcast gardener(true).update_tree!(Processes["test"], {'task' => 'b'} => {'task' => 'd'})
2011-06-14 23:40:22 utc ian-howcast so it looks for WIs with params task => b and prunes the new tree
2011-06-14 23:40:32 utc ian-howcast such that they land at task => d
2011-06-14 23:40:38 utc ian-howcast which works
2011-06-14 23:40:50 utc ian-howcast but it gets real gnarly with concurrency
2011-06-14 23:41:00 utc ian-howcast and I'm starting to wonder if this is the wrong approach
2011-06-14 23:41:34 utc jmettraux so it's a kind of migration gun ?
2011-06-14 23:41:41 utc ian-howcast precisely
2011-06-14 23:42:39 utc ian-howcast there are a few local abstractions, but I hope to contribute it once those are taken out
2011-06-14 23:42:59 utc jmettraux very interested
2011-06-14 23:44:14 utc jmettraux so, you need to preserve the wfids
2011-06-14 23:44:28 utc ian-howcast not necessarily
2011-06-14 23:44:31 utc jmettraux so that users/system are/is not confronted with a migrated flow that has a new wfid ?
2011-06-14 23:44:45 utc ian-howcast that *could* be fine
2011-06-14 23:44:49 utc jmettraux ok
2011-06-14 23:45:04 utc ian-howcast I was thinking that it might be easier to just do the "root rewind"
2011-06-14 23:45:09 utc jmettraux you're jumping workitems from one tree to the next, mapping by task name ?
2011-06-14 23:45:10 utc ian-howcast and then modify the workitems or something
2011-06-14 23:45:23 utc ian-howcast yes
2011-06-14 23:46:23 utc ian-howcast like if there was an easy way to jump the workitem from the beginning to an arbitrary subexp without pruning the tree and reapplying it
2011-06-14 23:47:03 utc jmettraux you mean, some kind of fast-forward ?
2011-06-14 23:47:24 utc ian-howcast yes, I believe so
2011-06-14 23:48:42 utc ian-howcast I had been looking at something like emulating a "jump" statement, but couldn't figure it out
2011-06-14 23:48:55 utc jmettraux always keeping this problem in a background thought thread
2011-06-14 23:49:14 utc jmettraux we could run the process with "blank" participants
2011-06-14 23:49:15 utc ian-howcast :D me too. Just ressurected this code after a year.
2011-06-14 23:49:35 utc ian-howcast ie. participants that just pass-thru?
2011-06-14 23:49:53 utc ian-howcast and then bring back the real participant defs?
2011-06-14 23:50:45 utc jmettraux during the resurrection run, the "not interesting" participant should pass through
2011-06-14 23:51:04 utc jmettraux and it should stop at the participant where we want the process to be
2011-06-14 23:51:33 utc ian-howcast makes sense. Seems little hacky...
2011-06-14 23:51:57 utc jmettraux for a simple sequence that is easy, but when "ifs" are involved, ...
2011-06-14 23:54:02 utc jmettraux or instead of blank participants, we could have participants that are smart
2011-06-14 23:54:15 utc jmettraux and seeing in the workitem that the work was already done, let it pass
2011-06-14 23:54:48 utc jmettraux (sorry for the word flood)
2011-06-14 23:55:22 utc ian-howcast ok. idempotent participants
2011-06-14 23:55:30 utc jmettraux exactly !
2011-06-14 23:55:52 utc ian-howcast so, is the "pruning" approach basically the same as what Ruote does internally with jump expressions?
2011-06-14 23:56:17 utc jmettraux inside a cursor yes
2011-06-14 23:57:21 utc ian-howcast I guess one cheap workaround would just to be to say you can only prune it to the nearest cursor. Jump has similar limitations if I recall correctly.
2011-06-14 23:58:30 utc jmettraux yes, but you can use :ref => 'x' to forward others to other cursors in the same process instance
2011-06-14 23:59:16 utc ian-howcast yes, but you can't, for instance, jump to the middle of a concurrency... which is what I'm kinda trying to do here ;)
2011-06-15 00:00:31 utc jmettraux if you have a concurrence expression in some tree, you could re-attach another expression as a child of the concurrence expression
2011-06-15 00:00:46 utc jmettraux but there is no handy method for that yet
2011-06-15 00:01:03 utc ian-howcast idempotent participants seems like a smart way to go long-term. Seems like an opportunity for some best practices to be wrapped up in a participant class (eg. pass_thru_if...)
2011-06-15 00:01:35 utc jmettraux right
2011-06-15 00:01:59 utc ian-howcast re: attaching the subexp as a child of the concurrence, that makes sense, and answers some of the problems I was running into
2011-06-15 00:02:43 utc jmettraux I wanted to add such transplating tools, but time is scarce
2011-06-15 00:03:04 utc jmettraux at least it's in the todo
2011-06-15 00:03:16 utc ian-howcast heh, I understand that one
2011-06-15 00:04:04 utc ian-howcast let me take another pass at doing it using pruning, since it seems the most globally applicable. I may come back with some questions.
2011-06-15 00:06:52 utc ian-howcast thanks for your thoughts thus far
2011-06-15 00:08:32 utc jmettraux you're welcome
2011-06-15 00:08:42 utc jmettraux have to go to the office, now, ciao !