Re: 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.

Yes, we did this for performance reasons. In some of my projects we had some
HUGE step tables, and since the most common access is only for current steps
it seemed to make sense.

> 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.

True... you can always write your own persistence store ;)

> 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?

We use HibernateWorkflowStore at work. The way to use it is to extends
AbstractWorkflow and override getPersistence().

-Pat




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge