This is a nice thought though I was actually trying to use stores for
another purpose...categorizing what a work item represents. E.g.
I have work items of many types, like approvals, filling out forms
etc.
and I may want to be able to do searches of that sort efficiently as
well.
I'm not 100% sure about how my application will get implemented,
however I do believe I'll need to find work items from a mass of
perhaps 1000's of them efficiently in several different search
dimensions.
In the end I'll be disabling your stores view from my application.
Users will get a 'dashboard' that shows work items that have been
targeted to them either directly or via groups they belong to.
I realize that modifying the base classes is a bad idea so what I
actually did do was build a new class in a different namespace that is
the modified version of the original.
To me the idea that work items have a target seems natural and in line
with how the real world application I'm trying to build would operate.
I had been originally playing with using a chunk of the participant
name as the target, but as that will require queries involving 'like'
terms I was afraid that would not scale as well to systems with large
numbers of in-flight work items.
Stores seemed un-natural to me somehow. But perhaps I'm missing
something. The proliferation of stores as you say is something that I
did not want to go to, as each store needs to be defined etc. etc.
and since I already need to define users and their groups it seemed
like prone to issues similar to that of duplication of data.
On Sep 20, 9:06 am, "John Mettraux" <[EMAIL PROTECTED]> wrote:
> On 9/20/07, rfoxmich <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > In thinking about how to build web applications that scale, where
> > workitems get dispatched to people or groups, I found the stores
> > scheme to be a bit unwieldy. My thinking is as follows:
> > - Work items can be dispatched to a person.
> > - Work items can be dispatched to a group.
> > - I should not need to iterate over the work items in a store or all
> > relevant stores
> > looking at parameters in each work item to select workitems meant to
> > be acted
> > on by a user or group.. that's what databases are good at.
> (snip)
>
> > sequence do
> > concurrence do
>
> > linemanager :target =>
> > "user:#{$processInfo['linemanager']}"
> > budget :target =>
> > "user:#{$processInfo['budgetmanager']}"
> > end
>
> > msuform :target => "group:travel"
> > end
> > end
>
> Hi Ron,
>
> at first you made me realize that I had completely forgotton to
> add_index to the workitems table. My bad.
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=14106&group_id...
>
> You're right. But somehow I would have done it a bit differently :
>
> 1). adding those forgotten indexes, on the participant_name and the
> store_name especially.
>
> 2). instead of adding a new column, I would extend the ActiveParticipant :
>
> ---8<---
> class SpecialActiveParticipant < ActiveParticipant
>
> def consume (workitem)
>
> target = workitem.attributes['params'].attributes['target']
> # simplified...
>
> store_name = if target
> target
> else
> "default_store"
> end
>
> Workitem.from_owfe_workitem(workitem, store_name)
> end
> end
> --->8---
>
> Here I use a special store_name based on the value in target.
>
> Feel free to use store_name or participant_name for your indexation
> purposes, as long as the "flow expression id" (fei) is left untouched,
> the engine, will recognize the workitem at reply time.
>
> Having many stores could be tiresome for Densha and its "stores" view,
> I could extend store permissions to support regular expressions (why
> not?).
> Or you could place your 'target' value in 'participant_name'
> ("#{participant_name}::#{target}"), leaving store_name untouched. Many
> possibilities.
>
> Trying to avoid modifying the schema, playing with the Ruby classes.
>
> Thanks for sharing your experience, best regards,
>
> --
> John Mettraux -///- http://jmettraux.openwfe.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwferu-users?hl=en
-~----------~----~----~----~------~----~------~--~---
