1) Imo, chopping it up is a workaround. It's more logical to have one BLOB for the attachment. If it works on all the QA supported databases, there's no reason to go again for the chopping.
2) DB2 has this limit (altough it can be configured to be set higher).
I don't think you can create a 'generic' DB DDL script. eg On mysql it is possible to use a TEXT column instead of VARCHAR, but I don't know for other DBs.
What people did in the past, is simply changing the DDL script according to the database.
3) Why can't process variables be cached?
on 2) : as long as we can postpone db specific handling, that will make development much easier and our progress much faster. db-specific things means that we would need a set of mappings for each db. that means that we would have to maintain and synchronize between all those copies.
so i'ld like to keep the same mappings for all the dbs. and if we need to apply a small modification for one particular db, it should be possible to apply this change automatically from the single original source mapping files.
on 3): cause that results in incorrect behaviour in a cluster. 2nd level cache of hibernate is only used for process definition caching as that can be assumed to be static information that (after deployment) will not change.
As far as I remember there was a lot of effort put in the chopping, and there is a good reason why it is there, or not?
In that case maybe it makes sense to just port the logic/code?
But if it works without as well I am with Jorram, skip every unecessary complexety....
the chopping code is ported to 4, but i'm not sure what is best to take as the default in this situation.
the reason was that chopping was better for database portability. i always thought that oracle was a difficult one. but that seems to work ok.
maybe since we have our own qa now, we can just use blob as the default and save ourselves a table and gain some performance.
Okay, then +1 for the blob as default
i always thought that oracle was a difficult one
Correct... it was indeed. Currently it isn't anymore
+1 for the blob
I agree we should use BLOB/CLOBs as the default and use the chopping only as needed. I don't even think we will find a *current* database/driver combination that does not support LOBs right. The four databases in continuous integration with jBPM 3 (HSQLDB, MySQL, PostgreSQL and Sybase) have no problem with CLOBs.
Koen wrote on the mailinglist
I agree on reducing complexity if there is no apparent regression.
But.... we should not forget migration...