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 ! |