@Julian: Your commits for CALCITE-1230 looks great! I assume those codes
are going to be exceptions returned by avatica when it's processing the
request before handing off to phoenix or some other processor. Is that
correct?
I am also wrapping up the golang driver. It should be ready for release
soon. One of the things that might be useful is to have an machine
readable "error_name" in the error response. For example, a phoenix
error_name might be "transaction_conflict_exception" or
"select_column_num_in_unionall_diffs". Reason for this is that
"error_message" provides a user readable message, however, if we want to
be able to say, retry if it's a transaction conflict, we would need to
check that error_code is 523. Comparing against a bunch of error codes
like 523 isn't as nice as doing error.ErrorName ==
"transaction_conflict_exception".
I currently have a map mapping all of phoenix's error codes to a machine
readable name like "transaction_conflict_exception" to achieve this in
my driver, but this might be very difficult to maintain.
This is probably something that phoenix needs to expose if this were to
be implemented.
Let me know what you guys think.
On 7/05/2016 11:37 AM, Julian Hyde wrote:
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?
