[
https://jira.jboss.org/jira/browse/JBPM-1685?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1685:
-----------------------------------
currently this is done with a hibernate text mapping. i think that also is portable
enough.
if later, we would want to switch, we can use the attached patch as a starting point. i
did start a refactoring at some point to change the String-text mapping to using our Lob.
but i changed my mind and kept the text mapping instead. But the patch for introducing
the Lob is attached in case we need it later.
Check persistence of exception field in JobImpl
-----------------------------------------------
Key: JBPM-1685
URL:
https://jira.jboss.org/jira/browse/JBPM-1685
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Guillaume Porcher
Priority: Minor
Fix For: jBPM 4.0
in jobs, there is a exception field to put the exception stacktrace
in hibernate mappings, this column length is set to 4000. Some stacktrace are more than
4000 char long, this creates an exception with hibernate.
<tomb> porcherg: the 4000 is because of some DB limitation
<tomb> i believe db2
<tomb> iirc, in db, the max string field is 4000
<tomb> if you want to go beyond that, we would need to use CLOBs
<tomb> but i'm open to alternatives
<tomb> maybe the stacktrace field should be a CLOB ?
<porcherg> tomb: the problem is that it creates an exception if it is too long
<tomb> yes
<tomb> so we have to fix it somehow
<tomb> just removing the 4000 limit is not good
<tomb> as it will not work on db2
<tomb> so we either manually truncate the exception field in the code
<tomb> in the setter
<tomb> or we change it into a clob
<tomb> probably the latter is better
<porcherg> maybe we can use hibernate "text" type
<porcherg> "text: Maps long Java strings to a SQL CLOB or TEXT type. "
<tomb> do you guys have access to db2 db ?
<tomb> the first thing we should do is verify if this problem is really present
<tomb> so we should remove the 4000 limit in the hibernate mappings and see if we
can create that problem on db2
<tomb> once we can reproduce it, then we can start looking for alternatives that
fix the problem on db2
<tomb> then we can see if the fix works on the other dbs
<tomb> i am a bit reluctant to start using clobs
<tomb> as this would be the first use case for it
<tomb> and clobs might lead to even more DB dependent issues...
<tomb> but if there is no other way, then we have to
<tomb> so let's start by removing the 4000 limit in the hibernate mappings and
prioritizing that we have to test it in db2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira