I'm adding binary process attachments to jbpm 4. I'm seeing things we need to
improve relative to jbpm 3. I'm seeing new possibilities. But I don't see
clearly the final solution yet. So please help fill my gaps:
1) chopping or blobs as the default strategy ?
* jBPM 3's capability to chop a blob into discrete sized chops and store a list of
those chops turned out to be very portable
* i thought that oracle was one of the most difficult db's with respect to plain
BLOBs. But currently in jBPM 4 this seems to work ok.
So the first question is: should we keep the chops as our default solution? Or can we
rely on our own QA now and give the BLOB's another try ?
I already build a Lob (Large OBject) hibernate entity that can store a java.lang.String or
a byte array in various ways (configurable). Then the handling of blobs and clobs
becomes kind of configurable in one central location instead of spread out over the whole
jbpm domain model.
2) Another aspect is the large text columns.
Here and there in the process definition datamodel and in the runtime datamodel, there are
text columns. Typically string is fine. But for some DB's this is limited to 4K (was
it ORA or DB2?). So we ended up truncating those strings.
Every string property that is potentially longer then 255 could a reference to such a Clob
entity.
3) The third aspect is process definition vs runtime blobs. Process attachments need a
blob, and storage of serialized objects also need a blob. Process attachments need to be
cached in hibernate's second level cache. While process variables cannot be cached.
So this doesn't really match with the configurable Blob and Clob approach that i was
buiding out. As hibernate cannot make a distinction between the process definition Blobs
and the variable Blobs.
All input appreciated : extra requirements, desired improvements, silver bullet
solutions,...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207739#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...