On Jan 10, 2008 10:12 PM, Tomaso Tosolini <[EMAIL PROTECTED]> wrote:
>
> On Jan 10, 2008 1:28 PM, John Mettraux <[EMAIL PROTECTED]> wrote:
> >
> > I agree with you entirely, but, there is a catch : it's not that bad
> > to have the fields in their own column, it allows for queries on them
> > like "return me all the workitems for which the field 'customer_name'
> > is set to 'Amerigo Vespucci'"...
>
> [...mumbling....]
> ok this is right, in the case of field name based search, but tends to
> become
> equally slow in the case of "google search", as implemented in the actual
> ActiveP.
> A possible solution is to implement a db treeization of the attributes, but,
> if every time
> i think to a simplification, this is the result we are at risk.... :)
(recapitaluting a bit)
So we have 3 possibilities
a). attributes are stored in one column of the workitem table
b). attributes are stored in the field table (current implementation)
c). tree of attributes in the field table
a).
+ faster at read/write
- have to load all the workitems to query on fields
b).
- slower at read/write
+ can do queries on top level attributes
c).
- super slow
+ can do queries on attributes at all levels (except maybe on sub
fields whose keys are not strings)
Is that it ?
(seems like we both don't like variant c). but do we see it the same way ?)
> > But your use case makes sense as well. So why don't we decide at
> > initialization time how the ActiveParticipant should deal with its
> > workitems ? Maybe the current behaviour should be the default and your
> > more straightforward behaviour could be enabled via something like :
> >
> > engine.register_participant "Amerigo", ActiveParticipant.new
> > :compact_workitems => true
> >
> > and then this parameter (we should find a decent name for it), would
> > be passed to the Workitem instances each time a workitem is consumed /
> > proceeded by the participant.
> >
> > Having an empty "field" table should not be a big deal.
>
> This is good for me.
>
> Two cases:
>
> 1. AP is able to handle at the same time workitems that were saved in the
> two ways.
>
> 2. AP, once started, can handle a single shape.
>
> if 1 then this info must be saved in the wi( as attribute inflow, and as
> special field in table, perhaps )
> if 2 this info is set at registration time in the ActiveP and the wis
> shouldn't be affected( am i wrong? )
>
> I like 1 best, you?
I like 1 as well, because it allows admins to change their mind later
and choose another behaviour. But that would mean that the Workitem /
Field classes are able to answer to queries, even when having a
heterogeneous set of workitems.
We could use variant 2 and have a rake task to migrate workitems to
the without field version and vice et versa.
What do you think ?
--
John Mettraux -///- http://jmettraux.openwfe.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
