Deciding assignments at the time of deployment is a totally wrong approach. Things might change while running the process. The pooled actors for a taskinstance might different to another instance although refering to the same swimlane. It certainly does for most of the processes we've created.. So each taskinstance having it's own pooled-actors, or refering to a swimlane is imo the right approach. That using swimlanes does not reduce it, by having e.g. the swimlanes for a processinstance refering to the pooled-actors table might be considered an 'issue' although I'm not to familiar with the internal workings of this part.
Do you have an example of the number of joins? Since (without looking at the query) my impression is that it is not to bad.
I have no issue with assignment at run time. In my mind the assignment is the join between the JBPM_POOLEDACTOR, and JBPM_TASKINSTANCE via the JBPM_TASKACTORPOOL.
Where I have issue is creating assignee's (POOLEDACTOR) when there are defined as part of the process definition. The fact that I declare a swimlane that defines a pooled_actor such as:
<swimlane name="Fraud"> <assignment pooled-actors="Fraud User"/> </swimlane>
would be a pretty good indication that this not going to change.
OK - I do understand that the list of pooled-actors can be determined at runtime via an expression, and in this case there is a need to store the actor at run times. But then why bother with the MANY-TO-MANY join then. Why not put the instance_id directly on the JBPM_POOLEDACTOR table. The same functionality could be achieved then with 2 joins instead of 3.
Here is an example of the query:
<query name="TaskMgmtSession.findPooledTaskInstancesByActorId"> <![CDATA[ select distinct ti from org.jbpm.taskmgmt.exe.PooledActor pooledActor join pooledActor.taskInstances ti where pooledActor.actorId = :swimlaneActorId and ti.actorId is null and ti.isSuspended != true and ti.isOpen = true ]]> </query>
What the query hides is the MANY-TO-MANY table that is part of the hibernate mapping definition:
... <set name="pooledActors" cascade="all" table="JBPM_TASKACTORPOOL"> <key column="TASKINSTANCE_" foreign-key="FK_TASKACTPL_TSKI"/> <many-to-many class="org.jbpm.taskmgmt.exe.PooledActor" column="POOLEDACTOR_" /> ... </set>
<set name="taskInstances" inverse="true" table="JBPM_TASKACTORPOOL"> <key column="POOLEDACTOR_" foreign-key="FK_TSKACTPOL_PLACT"/> <many-to-many class="org.jbpm.taskmgmt.exe.TaskInstance" column="TASKINSTANCE_" /> </set>
The three joins is compounded by a 4th join that I need to do to properly implement paging within our application. :(
The pooled actors can, ass you state be more than one id (e.g. as you have in a group). It can also be a list of individuals (I do not advise this to anyone, but it can be done). which can change over time and set via the api. But with your proposal that should still be possible.
What the query hides is the MANY-TO-MANY table that is part of the hibernate mapping definition:That is why I missed it, I try to stay away as much as possible from the hibernate mappings.
I doubt this will be changed in jBPM 3, but for the task component of jBPM4 it is certainly something to keep in mind (maybe Alex/Tom have already simplified this)
Thanks for the feedback