2010-09-09 08:35:48 utc |
dhf |
aloha. ok I give. I know you can get an array of all storage participants by their complete participant name like 'link_JUSTDESTINY' is it possible to get a list of storage participants that start with 'link_'? |
2010-09-09 08:36:09 utc |
jmettraux |
hello |
2010-09-09 08:37:14 utc |
jmettraux |
you'd probabaly have a unique storageparticipant |
2010-09-09 08:37:34 utc |
dhf |
there could be hundreds of participants starting with 'link_' some could have the same name but most are unique. Imy storage partcipant is catchall |
2010-09-09 08:37:45 utc |
jmettraux |
and then filter its content for all the workitems whose participant name starts with "link_" |
2010-09-09 08:38:27 utc |
jmettraux |
engine.storage_participant.all.filter { |wi| wi.participant_name.match(/^link_/) } |
2010-09-09 08:38:31 utc |
jmettraux |
or something like that |
2010-09-09 08:39:45 utc |
dhf |
so get a list of all and filter? that was what I was thinking I had to go to but was hoping I did not need to read the all. but not a problem |
2010-09-09 08:40:03 utc |
jmettraux |
let me look at the methods |
2010-09-09 08:40:18 utc |
dhf |
nothing i saw is storage participant |
2010-09-09 08:41:05 utc |
jmettraux |
http://github.com/jmettraux/ruote/blob/ruote2.1/lib/ruote/part/storage_participant.rb#L170-266 |
2010-09-09 08:47:29 utc |
jmettraux |
if those method do not suffice, please tell me and I'll find a better solution |
2010-09-09 08:56:28 utc |
dhf |
the first works. the second is exact match only. not regex. It would return 'link_DESTINY' if I use that as the parameter. Get to find all that start with 'link_' I can use the all and filter method it is basically what the query does anyway. |
2010-09-09 09:02:37 utc |
dhf |
the reason I am using the participant name like that is I need to find all taht start with link and do the link on the oldest participant then bring up each one with the same name and rehydrate each of them to finish. They are all pending for someone to establish the account. that must be a manual process. Once done, all pending need to be finished. Each one processes a unique document. It might work to name it 'link' only and use the query to find a |
2010-09-09 09:02:38 utc |
dhf |
with teh same name |
2010-09-09 09:05:42 utc |
jmettraux |
ok, I usually hand that to a specific user or group of users |
2010-09-09 09:05:53 utc |
jmettraux |
pile-wise |
2010-09-09 09:07:06 utc |
dhf |
I agree with group. How do you specify a group in ruote? |
2010-09-09 09:07:15 utc |
jmettraux |
you don't |
2010-09-09 09:07:27 utc |
jmettraux |
participant "group_alpha" |
2010-09-09 09:07:40 utc |
jmettraux |
engine.storage_participant.by_participant('group_alpha') |
2010-09-09 09:13:08 utc |
dhf |
then use the field and name query to rehydrate after the work is done on the first one? The rest just ned to go on to next step. the manual work has been done on the first one. I think that will work. I can actually a query based upon the name and the launch time. |
2010-09-09 09:13:41 utc |
jmettraux |
what is "rehydrate" ? Refill the task list ? |
2010-09-09 09:18:44 utc |
dhf |
sorry. yes reactivate the pending process. They are al waiting for some one to manually create the account. once done. I will go through each pending one for the same person and reply with the same account information in the workitem, so the rest of the process can complete. Prior to ruote it was stored in a DB work table. the person name as the primary key and the information necessary to finish processing after the account was created. nots of co |
2010-09-09 09:18:44 utc |
dhf |
like the ruote approach better. it is just a pending stem in the process. That way it does not matter what the next steps are. |
2010-09-09 09:19:39 utc |
jmettraux |
:-) |
2010-09-09 14:01:32 utc |
lbt |
http://github.com/jmettraux/ruote/wiki seems to have gone away |
2010-09-09 14:04:15 utc |
jmettraux |
lbt: hello, sorry |
2010-09-09 14:04:23 utc |
jmettraux |
I have a copy here locally |
2010-09-09 14:04:34 utc |
lbt |
:) |
2010-09-09 14:04:57 utc |
jmettraux |
I triggered the upgrade to the new "gollum" wiki engine github haz |
2010-09-09 14:04:58 utc |
jmettraux |
has |
2010-09-09 14:05:08 utc |
lbt |
*poof* |
2010-09-09 14:05:29 utc |
jmettraux |
yeah, it's reacting weirdly |
2010-09-09 14:05:49 utc |
jmettraux |
I want to put it back in order soon |
2010-09-09 14:06:03 utc |
lbt |
well, no rush here. I was just pointing to it |
2010-09-09 14:06:10 utc |
jmettraux |
thanks ! |
2010-09-09 14:14:29 utc |
jmettraux |
lbt: how's the team progressing ? |
2010-09-09 14:15:26 utc |
lbt |
Mainly getting up to speed I think |
2010-09-09 14:15:42 utc |
lbt |
I'm expecting a review early next week |
2010-09-09 14:16:10 utc |
lbt |
(that's on the perf testing side) |
2010-09-09 14:16:55 utc |
lbt |
we've launched BOSS (ruote+rabbit+... really) internally and are starting to use it with triggers from the build system |
2010-09-09 14:17:17 utc |
jmettraux |
:-) |
2010-09-09 14:17:18 utc |
lbt |
So our test team are writing a participant as we speak |
2010-09-09 14:17:43 utc |
lbt |
We've agreed to use it for the meego.com community build system QA processes |
2010-09-09 14:18:10 utc |
lbt |
so when apps are built etc, they'll go through various reviews and auto-tests |
2010-09-09 14:18:30 utc |
lbt |
including manual breakout if needed and auto-promotion |
2010-09-09 14:18:34 utc |
lbt |
that's all BOSS |
2010-09-09 14:18:49 utc |
lbt |
then the core distro will also be using it for their work. |
2010-09-09 14:19:16 utc |
jmettraux |
so a small initial process to let the team get a feel for it ? |
2010-09-09 14:19:17 utc |
lbt |
I need to setup some infra for them now... I need to do some security design work for that |
2010-09-09 14:19:25 utc |
lbt |
yes... absolutely |
2010-09-09 14:19:42 utc |
lbt |
we're also looking at a git-store for the processes |
2010-09-09 14:20:13 utc |
lbt |
so we'll have a launcher... and it'll pull a process from git based on certain conditions and launch via AMQP |
2010-09-09 14:20:24 utc |
lbt |
event driven |
2010-09-09 14:20:34 utc |
lbt |
so that process can grow |
2010-09-09 14:20:54 utc |
jmettraux |
cool |
2010-09-09 14:21:00 utc |
lbt |
yeah... :) |
2010-09-09 14:21:15 utc |
lbt |
We really aren't pushing ruote yet though |
2010-09-09 14:21:27 utc |
lbt |
tiny processes, very linear |
2010-09-09 14:22:03 utc |
jmettraux |
versioning the process, that's nice, I'm always suggesting it to people, but they "want to put it in the database" |
2010-09-09 14:22:30 utc |
jmettraux |
there's a URI for anything these days.... |
2010-09-09 14:22:37 utc |
lbt |
he |
2010-09-09 14:22:41 utc |
lbt |
h |
2010-09-09 14:23:06 utc |
lbt |
https://gist.github.com/1d2371319225d9eec0b4 |
2010-09-09 14:23:53 utc |
jmettraux |
very nice ! |
2010-09-09 14:24:41 utc |
jmettraux |
tight |
2010-09-09 14:25:05 utc |
lbt |
thankyou |
2010-09-09 14:25:37 utc |
lbt |
it's the approach... clearly some work to do yet :) |
2010-09-09 14:26:07 utc |
lbt |
I'm getting interested in a mechanism to do notification and human interaction |
2010-09-09 14:26:39 utc |
lbt |
often a "yes/no" for a particular question (with enough context to allow them to make the decision) |
2010-09-09 14:26:52 utc |
lbt |
bbias |
2010-09-09 14:29:03 utc |
lbt |
the other area I'm starting to ponder is signing :) |
2010-09-09 14:29:56 utc |
jmettraux |
aaah |
2010-09-09 14:29:57 utc |
lbt |
having parts of the wi signed in some way to allow trust to be maintained in a distributed workflow. |
2010-09-09 14:30:17 utc |
lbt |
but that's very much at the participant level I think |
2010-09-09 14:30:40 utc |
lbt |
it's an interesting and fun problem |
2010-09-09 14:30:46 utc |
jmettraux |
:-) |
2010-09-09 14:31:59 utc |
lbt |
anyhow... back to some DB design ... :) |
2010-09-09 14:32:12 utc |
lbt |
and some coffee.... mmmm ..... nice wife! |
2010-09-09 14:32:20 utc |
jmettraux |
enjoy ! |
2010-09-09 14:32:27 utc |
lbt |
o/ |