Hey Julian,
I was not able to find 42900 in the SQLSTATE here[1], so it might be a
Phoenix specific one.
523 appears to be an error code specific to phoenix. I also found
CALCITE-1049 and CALCITE-1187 which appears to report the same problem,
so hopefully this is something that will be improved in the future.
Anyway, this is something I can work around by examining the error
message for now.
Cheers,
Francis
[1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
On 6/05/2016 5:40 AM, Julian Hyde wrote:
It makes sense that Avatica should propagate error codes. Especially
if they adhere to the SQL_STATE standard.
By the way Calcite doesn't do a good job of this. It has
https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
but there are only 3 codes defined.
It looks as if Phoenix does a lot better.
Julian
On Thu, May 5, 2016 at 2:29 AM, F21 <[email protected]> wrote:
I recently found more time to work on the golang driver for avatica/phoenix
query server.
One of the things I want to do is to be able to trap transactional
conflicts. Here's one of them:
exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR 523
(42900): Transaction aborted due to conflict with other mutations. Conflict
detected for transaction 1462439936409000000.\n\tat..."
error_code:4294967295 sql_state:"00000"
metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
I noticed that the sql_state is usually 00000 as per
https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
However, I am not sure what 4294967295 means as I cannot find it if I grep
the calcite or phoenix code base. Interestingly, 4294967295 is the maximum
value of an unsigned_int. If I cause other errors such as
PhoenixParserException, the error code is also set to 4294967295.
Is there any reason why the sql_state and error_code from phoenix (42900
and 523) is not being used in the error response?
