On Fri, Jul 22, 2011 at 4:28 PM, John Mettraux <[email protected]> wrote: > Hello, > > sorry for the surprise. This was meant to be smoother than that. > > http://groups.google.com/group/openwferu-users/browse_thread/thread/1ed5c8bb75b139bd > > Does the issue only come up when replying to the storage participant ?
yes. > > What about muscling up temporarily Ruote::StorageParticipant#fetch to do a > sequential search among workitems with the same wfid if the regular fetch > routine yields nil ? Instead, we did this, which seems to fix the problem: https://gist.github.com/1100812 That is, only move the sub_wfid to the subid the first time through. > > Are there other issues coming up ? Yes, now we're hitting a problem where ParticipantList#instantiate expects pinfo to be an array. We verified that newly created processes store the participant in the format it expects, eg. ["FooParticipant", {}] While our legacy processes store it as a simple string ("FooParticipant"). Here's the monkey patch that seems to have fixed that for the moment: https://gist.github.com/1100818 . Do you have feedback on the patches? Are there other data migration issues we should be looking out for? Is there an easy way to get all our legacy data into a schema that Ruote 2.2.0 will play nicely with? Thanks, Ian > > > Best regards, > > -- > John Mettraux - http://jmettraux.wordpress.com > > -- > you received this message because you are subscribed to the "ruote users" > group. > to post : send email to [email protected] > to unsubscribe : send email to [email protected] > more options : http://groups.google.com/group/openwferu-users?hl=en > -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
