Currsor get error #108
Currsor get error #108
Conversation
Code Coverage
Files
|
| assertSame(EExecutedOp.ERROR, cursor.getOp()); | ||
| CodecError rowError = cursor.getError(); | ||
| assertNotNull(rowError); | ||
| assertEquals(UNIQUE_VIOLATION_CODE, rowError.err.value()); |
There was a problem hiding this comment.
Based on how @xeus2001 explained, this was expected to return XyzErr.CONFLICT . If we have now decided to return actual Postgres error back, that is also fine as we haven't started with psql alignment yet. But we need to ensure there is consistent agreed error handling going forward (and so the next question will be, how will no-data-found error will be returned for Update scenario? .. and same question for UUID conflict error for Update operation)
There was a problem hiding this comment.
I was not aware, I will change it to CONFLICT then.
Can UUID conflict be the same CONFLICT?
I will cover other cases by tests.
There was a problem hiding this comment.
I agree to this, but maybe we can make this a two step fix. So lets first approve this change, as it improves the situation and then ensure that we somehow translate the unique violation code into a CONFLICT.
There was a problem hiding this comment.
Ok, so we then continue with XyzErr specific codes. Yes, it makes sense not to hold this PR, as we haven't started with psql alignment yet, so no impact.
No description provided.