[jbpm-issues] [JBoss JIRA] Commented: (JBPM-1685) Check persistence of exception field in JobImpl

[Guillaume Porcher (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBPM-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12425423#action_12425423 ] 

Guillaume Porcher commented on JBPM-1685:
-----------------------------------------

removing length="4000" creates a varchar(255) (default string length in hibernate)

> 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) 
>          Components: PVM
>            Reporter: Guillaume Porcher
>            Priority: Critical
>
> 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