topic Re: Data Model Review in Alfresco Archive

Data Model Review

robin1 — Fri, 29 Jun 2012 18:15:23 GMT

Hi guys,I've been taking a look at the Data Model for Activiti and noticed some areas that can be improved. If I'm off on any of these, please comment back.The Activiti tables fall into 3 categories: • Identity• Engine• HistoryThe Identity tables are:• ACT_ID_GROUP• ACT_ID_MEMBERSHIP•

Re: Data Model Review

frederikherema1 — Mon, 02 Jul 2012 12:30:20 GMT

the relationships between the tables are all messed up

I would be careful making statements like these My two cents on this:

1. Looking up tasks by process-definition ID is a VERY common use case. Since a single process can have multiple child-executions (and that can have more children as well), this would require extra joins (execution -> process instance -> process definition). We decided to add extra column… The increase in performance is more relevant than the extra column.

2. Since activity DOESN'T INFORCE CHECKING on candidates and groups on a task, there are no foreign keys. This is an explicit choice rather dat just "being all messed up". This way, activiti can also be integrated better with other identity-management solutions whiteout explicit ally having to have physical "user" and "group" records available. Keep in mind, activiti.jar is an engine, not a full product and is most likely to be used inside another apps, which can have their own ACL stuff…

3. A task is never "assigned" to a group… A group can be "candidate" for the task. So if no user explicitly claims a task, the finished task will have NO assignee. Again, activiti is a library. You could easily enforce your services to first CLAIM a task before completing. This way, assignee is always preserved (this is done in alfresco, for example).

4. The task-history contains all there is to the task, we're not going to invent fields Task-variables CAN be stored as del in history depending on the history-settings…

I hope these answers take a way some of the concerns raised by this post?

Re: Data Model Review

robin1 — Tue, 03 Jul 2012 15:29:06 GMT

Thanks for the reply frederikheremans - very well written response and I'm glad to see that clearly a lot of though went into the data model.

I've got a quick follow up question and I think it leads to something I'm not understanding - should there be a foreign key constraint between
ACT_RE_PROCDEF. ID_ and ACT_RU_EXECUTION. PROC_DEF_ID_?

Robin

Re: Data Model Review

frederikherema1 — Wed, 04 Jul 2012 06:49:32 GMT

Since there shouldn't be any executions/process-instances for an inexistent process-definition. When using the API, there is no way of deleting a process-definition without cascading all process-instances and there sub-executions. So in theory, constraints are enforced by the engine.

However, in some queries, they are joined (e.g.. ExecutionQuery.processDefinitionKey(…)) and it would definitely make sense to add a foreign-key constraint and/or and index on those fields. https://jira.codehaus.org/browse/ACT-1279

Re: Data Model Review

bernd_ruecker — Fri, 03 Aug 2012 18:03:10 GMT

[x] done