> On May 12, 2016, at 10:49 PM, F21 <[email protected]> wrote: > > @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?
It’s mainly reference data. If someone is implementing an Avatica server, when they throw an error, they are strongly encouraged to populate its sqlState value if it corresponds to a standard error. This table will make it easier for those implementers. But Avatica will just pass through whatever sqlState value it gets. > > 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. Avatica’s ErrorResponse currently has the same information as JDBC (String sqlState, int errorCode, String errorMessage). I don’t think it’s wise to add an errorName field, because it would be difficult to propagate it with a JDBC SQLException. If the error being thrown has a sqlState, then the sqlState code is sufficient. You can look up the name, e.g. SqlState.BY_CODE.get(“01004”).name() evaluates to “WARNING_STRING_DATA_RIGHT_TRUNCATION”. If the error being thrown is not a standard sqlState, I don’t think there is a problem putting the error name in the sqlState field. SQLException doesn’t check whether the code is valid, or even that it is 5 chars long. Julian
