[forge-issues] [JBoss JIRA] (FORGE-2490) Handling of unique constraint exceptions

[George Gastaldi (JIRA)]

     [ https://issues.jboss.org/browse/FORGE-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Gastaldi updated FORGE-2490:
-----------------------------------
    Comment: was deleted

(was: Hi [~aitorfcj], 
Have you tried enabling Bean Validation in your JPA descriptor?  JPA shouldn't delegate validation to your DB.
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_jpa)


> Handling of unique constraint exceptions
> ----------------------------------------
>
>                 Key: FORGE-2490
>                 URL: https://issues.jboss.org/browse/FORGE-2490
>             Project: Forge
>          Issue Type: Feature Request
>          Components: Scaffold
>    Affects Versions: 2.19.2.Final
>         Environment: Faces 2.2, Hibernate, Oracle 11g, WildFly 8.2
>            Reporter: Aitor Fdez-Ceballos Jiménez
>             Fix For: 2.x Future
>
>
> If you scaffold an Entity in which you have an unique constraint (i.e: java-add-annotation --onProperty testField --annotation Column(unique=true)) the generated code isn't able to handle the exception when you violate the unique, unlike other restrictions, and redirects the user to the general error page, losing the inserted data.
> Reading about this my conclusion is that JPA doesn't manage this and delegates to the database. Anyway, It would be great if the generated Forge beans could handle the restriction just like with the others and show a validation error instead of redirecting to the error page.
> I have tried with two different approaches to manage this:
> 1) Flush after the persist/merge in the bean so we can catch the SQLIntegrityConstraintViolationException in the update method and then add a proper message.
> 2) Launch a previous select query to the database to see if the value is already in the database (not very efficient / smart)
> Following the option 1 we faced another problem and we have finally extended ours beans from a "general bean" in which we have an interceptor method with @AroundInvoke annotation to handle errors from the database. This appear to be necessary sometimes when we get an EJBTransactionRolledbackException (i.e when you are editing [not creating] an object, because the exception is launched in CMTTxInterceptor so we cannot catch it in the update method)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)