OSWorkflow: Questions about database design and HibernateWorkflowStore

I noticed that you have a current table and a history table.  I can't seem
to figure out the need for a separate history table. If you just had a
CUR_STEP table and the cross-reference table linking the steps together, I
think that would be sufficient. You could query for only current steps by
selecting all steps that have a null finish date.

I suppose having 2 tables keeps the size of the current step table down and
thus might have a minor performance improvement. But, I think this is offset
by the performance hit of having to do multiple inserts, deletes, updates
and selects when transitioning the workflow ( ESPECIALLY if you're using
OwnerOnlyCondition, which performs a select in a for loop!).  With one
table, you could gain a 50% boost in workflow transition performance.

Second question... HibernateWorkflowStore. It doesn't look like it is fully
implemented yet. Also, the constructor takes in a Session object, but your
StoreFactory can't pass args to the constructor... only via the init()
method.  I like Hibernate. Is any work being done in this area?

Finally, while implementing a BC4J workflow store (our shop is way too into
Oracle technology), I noticed a potential bug in AbstractWorkflow line 857.
You check for dueDate != null, but the workflow definition XML Parser
apparently reads it in as an empty string the dueDate attribute is not
present on the result descriptor element.  This results in a
DateFormatException (or something...don't exactly remember) when you try to
parse the "" date String.  I added a && !"".equals( dueDate ), and its all
good.

This causes thanks for your input.





-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com