On 13/05/2016 5:30 PM, Julian Hyde wrote:
Avatica’s ErrorResponse currently has the same information as JDBC (String
sqlState, int errorCode, String errorMessage). I don’t think it’s wise to add
an errorName field, because it would be difficult to propagate it with a JDBC
SQLException.
If the error being thrown has a sqlState, then the sqlState code is sufficient.
You can look up the name, e.g.
SqlState.BY_CODE.get(“01004”).name()
evaluates to “WARNING_STRING_DATA_RIGHT_TRUNCATION”.
If the error being thrown is not a standard sqlState, I don’t think there is a
problem putting the error name in the sqlState field. SQLException doesn’t
check whether the code is valid, or even that it is 5 chars long.
Julian
Ah that makes sense with the ErrorResponse being tied to SQLException.
Unfortunately, as a client of the avatica server, I am unable to call
`SqlState.BY_CODE.get(“01004”).name()` and will still need to maintain
my own map of error codes to the exception name.
Maybe it's possible to get an AST representation of
https://github.com/apache/phoenix/blob/a0504fba12363eaa27ea3fd224671e92cb11a468/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java
to manipulate it into a language agnostic format, but I think that's
over engineering things for now.
The best solution is probably to maintain my own map and get a diff of
SQLExceptionCode.java on every release and add/remove error codes.
