You inspired me to add SQLSTATE reference data to Avatica, as a new enum SqlState[1]. Reviewing SqlState.java[2] I can say for sure that 42900 and 523 are not standard codes.
Please review SqlState.java before it goes into Avatica. Is there anything we can add to make it more useful to client applications? Yes, what you are seeing duplicates 1049 and 1187. Would anyone like to work on these? Julian [1] https://issues.apache.org/jira/browse/CALCITE-1230 [2] https://raw.githubusercontent.com/julianhyde/calcite/1230-sql-state/avatica/core/src/main/java/org/apache/calcite/avatica/SqlState.java > On May 5, 2016, at 4:59 PM, F21 <[email protected]> wrote: > > 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? >>> >>> >
