search

diesel-rs / diesel

A safe, extensible ORM and Query Builder for Rust
https://diesel.rs
Apache License 2.0
12.79k stars 1.08k forks source link

Expose error code for PG backend #4290

Closed jrandolf closed 1 month ago

jrandolf commented 1 month ago

This allows for robust handling of PG errors that are not already enumerated.

weiznich commented 1 month ago

Thanks for opening this PR. Could you provide some more details about which SQL Error codes you want to handle outside of diesel and why that's required.

Additionally: I fear we cannot merge the PR as it is as it contains a breaking change (adding a new required method to an public trait).

Finally: There should be at least one test for this.

jrandolf commented 1 month ago

I'd like to handle exclusion errors, but possibly others if they come up. I'd rather not file a PR for each case though, so it makes more sense IMO to just expose the code. After all, sql state is somewhat standardized AFAIU. Perhaps not the codes themselves, but the concept of a code itself.

I will add a test.

Would you like me to just add a default implementation to code?

Ten0 commented 1 month ago

I'd like to handle exclusion errors, but possibly others if they come up. I'd rather not file a PR for each case though, so it makes more sense IMO to just expose the code

IMO adding those to DatabaseErrorKind will result in a more readable and less error-prone code when matching on those errors, and in addition it wouldn't be a breaking change, as documented on DatabaseErrorKind (which is also marked as #[non_exhaustive]). Adding the 2 or 3 "Integrity Constraint Violations" that are still missing there would seem reasonable, and I would tend to imagine that that represents most of the "other cases that one may want to catch later on".

I'm not opposed to adding the method currently suggested by this PR but the above feels like a reasonable first step given the compromise that there is otherwise between backwards compatibility (previously mentioned breaking change) and correctness (any existing implementation of this trait is unlikely to be as correct as it should be if we add a default impl for this method).

jrandolf commented 1 month ago

@Ten0 Alright, I've just added the remaining constraints to the enum. Do you folks want test for these errors or is this sufficient?