On Sep 15, 2009, at 5:50 PM, John Mettraux wrote:
>> (2) Figured out how to override wfidgen and errorjournal today (very
>> easy!). in doing so though, I realized that the other subsystems rely
>> on wfidgen's mkdir(work), so I have to manually mkdir(work).
>
> Yes, you have to provide a #split method in your WfidGenerator
> implementation. FsStorage for example uses it to determine its
> subdirectories structure.
OK, so my WfidGenerator is derived from HashWfidGenerator, and I
overrode generate, + context= (to prevent last_save/etc). so,
technically, I do have a split() method (inherited from yours) -- but
it seems to me that the FsStorageEngine itself should be pre-creating
that directory before it calls build_*.
In my case, I use ruote-dm, and (as you know) DmStorageEngine derives
from FsStorageEngine, overriding only the expression storage -- which
leaves everything else still using filesystem storage. Given that any
build_* might be arbitrarily overridden, shouldn't either (1) the
engine be responsible for creating that dir, or (2) each "service"
that relies on it should verify it's there (not very DRY)?
>> Questions:
>>
>> (1) Can you explain the practical use for the inclusion of the word
>> "engine" in the 'engine|wfid|expid' wfid/expid/etcs?
>
> Was thinking of two completely different engines sharing the same
> storage (not a very good idea perhaps) or simply 1 engine per
> sub-organization and workitems zipping around. May help routing
> workitems back to their origin engine.
Hmm. Where's the engine name set? For me, I think I'd rather set it
to "1" as a quick optimization eliminating redundant data.
>> (2) Any idea why whenever I "return" from a block participant (due to
>> a detected error condition usually), I get this sort of error (my own
>> formatting, but you get the gist):
>> 2009-09-15 13:20:08 ERROR </engine|20090911-bokishineki_44|
>> 0_0_0_0_7_2_0_0_0> ThreadError: return can't jump across threads
>> ({:workitem=>#<Ruote::Workitem:0x107500cc8 .... })
>
> OK,
>
> try to run that piece of Ruby code :
>
> ---8<---
> Thread.new do
> return :nada
> end.join
> --->8---
>
> Since block participant, by default, lets the engine wraps its consume
> action in a Thread, that triggers your error.
Ohh, is that the synchronous/synchronized flag I saw somewhere?
> I learned that the hard way a couple of years ago. I know the pain. (I
> love the short-circuit coding as well).
Ahh crap, seriously? Man.. I have an arbitrary # short-circuit exit
conditions, and (useful) logging for each error.. I guess a kludge
would be to accumulate errors up until I get to do_the_job, but that's
not very practical since there are also arbitrary non-error exit
conditions.
Is there *anything* I can do to exit the callback early? Maybe a
break since it's inside a closure? Or is there some neato ruote-ism
we can shoehorn in?
cheers,
--jordan
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
