I agree. https://issues.apache.org/jira/browse/CALCITE-1049 <https://issues.apache.org/jira/browse/CALCITE-1049> is about this. Phoenix helpfully returns both a sqlState and a (I presume Phoenix-specific) error code, and Avatica has slots {errorMessage, errorCode, sqlState, severity}, somehow the sqlState doesn’t get populated.
> On May 6, 2016, at 10:55 AM, James Taylor <[email protected]> wrote: > > From a clients perspective, it'd be nice in Avatica if you kept the > sqlstate and error code that's thrown on the server side. I'm sure all the > different adapters vary widely in terms of the codes they use and clients > may depend on these (especially the particular error code). > > Thanks, > James > > On Fri, May 6, 2016 at 10:46 AM, Julian Hyde <[email protected]> wrote: > >> 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? >>>>> >>>>> >>> >> >>
