[
https://issues.apache.org/jira/browse/TORQUE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475765#comment-13475765
]
Thomas Fox commented on TORQUE-233:
-----------------------------------
A constraint for solving this is that we do not want Torque to depend on the
various driver classes.
So a feasible way seems to be to look at the sqlState of the SQLException (this
seems to be standardised a bit) and check whether the sqlState matches a
certain pattern.
This seems feasible so far (checked derby, mysql, postgresql) for constraint
violations (though finding out whether the constraint is a unique key, foreign
key, not null constraint is not possible in mysql) and for deadlocks.
I'll create a possible solution and test cases and then check with other
databases
> Exception translation
> ---------------------
>
> Key: TORQUE-233
> URL: https://issues.apache.org/jira/browse/TORQUE-233
> Project: Torque
> Issue Type: Wish
> Components: Runtime
> Affects Versions: 4.0-beta1
> Reporter: Thomas Fox
>
> Currently, there is no portable way to determine the reason of an Exception.
> E.g. if an exception occurs during saving, it could be due to a unique key
> violation.
> It would be nice such a Violation would result in a special subclass of
> TorqueException, so the reason could be determined in a way portable across
> databasess
> (Currently one can look at the root cause of the Torque exception and then
> e.g. form ysql check whether it's a
> MySQLIntegrityConstraintViolationException, but of course this is not
> portable across databases)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
