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? > >
