Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Pending code changes (auto-populated)
View issue level access limits(Press Alt + Right arrow for more information)
Request for new functionality
View staffing
Description
This will create a feature request which anybody can view and comment on.
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
I would like Cloud Spanner to provide more granular error details when a unique constraint violation occurs during insert operations using Mutation API. Specifically, it should be possible to discern which table and which unique constraint was violated to enable more precise error handling and recovery processes.
In situations where a violation of a specific unique constraint is anticipated, while others should not be violated, handling just an
AlreadyExists
error is not sufficient to identify the root cause.How this might work:
When a unique constraint violation occurs, the error returned by Cloud Spanner should include not just an message that a constraint violation has occurred but also include details which specific constraint (ideally both the table name and the constraint or index name) was violated. This could be implemented by enhancing the gRPC error payload to include these details.
If applicable, reasons why alternative solutions are not sufficient:
One alternative would be using ReadWrite transactions to pre-check for unique constraint violations before insertion by reading. However, this increases communication with the server and the possibility of transaction aborts, which degrades performance.
Another method would be to use DML for insertion, but this also might have poorer performance compared to the bufferable Mutation API.
The gRPC Status's message does include the table name and index, but these messages are not part of a standardized API and are subject to change, making any code based on these messages unreliable.
Other information (workarounds you have tried, documentation consulted, etc):
Attempts to retrieve the details error information from the details of the gRPC Status, but it did not contain the necessary information.