Workitem field disappears unless process(workitem) is called from StorageParticipant on_workitem

[eric....@bluewaterbrand.com]

Hello Ruote community,

I have a Ruote::StorageParticipant subclass which is setting a workitem field in its on_workitem method. If I call proceed(workitem) directly from the on_workitem method, the workitem field I set is available from the next participant's on_workitem method. This is expected behavior.

There are cases where I do not want to proceed immediately. In these cases I call update(workitem) and let the on_workitem method return. After calling update(workitem) I can see that the ruote table contains a JSON key/value pair for my workitem field (when using Ruote::Sequel::Storage). However, those fields are not available when I retrieve the workitem with ruote_dashboard.storage_participant[ruote_fei].  The behavior is identical whether I use Ruote::Sequel::Storage or Ruote::HashStorage.

Attached is a sample script which demonstrates this behavior.  It can be run in 2 ways:

> ruby ruote-workitem-field-update-test.rb process

> ruby ruote-workitem-field-update-test.rb update

Passing the 'process' argument shows the expected behavior.  Passing the 'update' argument shows the unexpected behavior (the workitem value is nil).  It seems like the storage_participants :[] method is returning a cached, stale workitem.  What am I doing wrong?  Am I using ruote incorrectly?

Any help would be appreciated.

Thank you.

[Hartog De Mik]

I use storage participant to ...store stuff, logicly you could decide to instantly reply, but imho the essence is not to reply and let the process sit right there, until some external force re-applies or proceeds.

I am a naughty boy and I let the external force update my workitems from outside the process (yes; I know this may be seen as evil)

Basicly; it boils down to this code snippet

```

storage = dashboard.storage_participant

workitem = storage[fei]

workitem.fields['value'] = 'The Value!'

storage.proceed(workitem) 

```

Judging by the code you provided; you can fill in the blanks ;)

John might have a better answer, perhaps even with explanation! :))

Grtz,

Hartog

2013/8/14 <eric....@bluewaterbrand.com>

--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Mettraux]

> 2013/8/14 <eric....@bluewaterbrand.com>
>
> > Hello Ruote community,

Hello Eric,

welcome to the ruote mailing list.

> > (...)

> >
> > Attached is a sample script which demonstrates this behavior. It can be
> > run in 2 ways:
> >
> > > ruby ruote-workitem-field-update-test.rb process
> > > ruby ruote-workitem-field-update-test.rb update
> >
> > Passing the 'process' argument shows the expected behavior. Passing the
> > 'update' argument shows the unexpected behavior (the workitem value is
> > nil). It seems like the storage_participants :[] method is returning a
> > cached, stale workitem. What am I doing wrong? Am I using ruote
> > incorrectly?

Ah, ok. the update fails. I've modified your code so that it makes it
apparent:

https://gist.github.com/jmettraux/3d17e343305f5650a1ea

It's OK to subclass the storage participant (I think I even advised it
sometimes on this mailing list...) So your could should work.

Here is a fix:

https://github.com/jmettraux/ruote/commit/e4d7b00

It makes sure what is returned by StorageParticipant#workitem has the current
"_rev" so that the following update is successful.

(I will make sure thate StorageParticipant#update updates the _rev as well,
so that update can be called multiple times in a row.

On Wed, Aug 14, 2013 at 10:07:14PM +0200, Hartog De Mik wrote:
>
> I use storage participant to ...store stuff, logicly you could decide to
> instantly reply, but imho the essence is not to reply and let the process
> sit right there, until some external force re-applies or proceeds.
>
> I am a naughty boy and I let the external force update my workitems from
> outside the process (yes; I know this may be seen as evil)

This is the vanilla use case, evil vanilla? ;-)


Best regards, I hope this helps,

--
John Mettraux - http://lambda.io/jmettraux

[eric....@bluewaterbrand.com]

Thank you very much!  I hope to contribute once I get over the newbie learning curve.