Better error system

[tyt2y3]

Continue #750

[tyt2y3]

@mohs8421

[Sculas]

Any updates on this?

[billy1624]

Hey @Sculas, we'll do a final review then merge it :)

[tyt2y3]

Actually I strongly appreciate another pair of eyes to look at this

[Sculas]

Would an error like UniqueConstraintError be out of scope for SeaORM? If not, maybe some other uncommon errors too? Just to make it easier for the user. If it's not out of scope I'm willing to make a PR for it.

[ikrivosheev]

Would an error like UniqueConstraintError be out of scope for SeaORM? If not, maybe some other uncommon errors too? Just to make it easier for the user. If it's not out of scope I'm willing to make a PR for it.

This is needed very often when writing applications.

[Sculas]

This is needed very often when writing applications.

Yeah. I currently have some function that matches the error and checks if it's a unique constraint violation. It would be so much better if you could just check if it's a DbErr::UniqueConstraintViolation, for example.

[billy1624]

I think UniqueConstraintError can be a variant of RuntimeErr.

[mohs8421]

@Sculas that was my original intention with this discussion and the pull request in general. This pull request is now merely laying the foundation for what you suggest. There will be more after this one is done. See the discussion and my original PR. But yes effectively speaking it will help a lot to have all those typical database runtime errors be reflected by seaorm, like fk-related errors or deadlocks which might even be circumvented by a retry mechanism.

[tyt2y3]

Thanks for the suggestion @ikrivosheev

[tyt2y3]

I think UniqueConstraintError is only applicable to Exec, not Query ?

[Sculas]

I think UniqueConstraintError is only applicable to Exec, not Query ?

That sqlx error that contains the unique constraint error is currently mapped to Query, so that would need to be changed.

My review in #750 mapped the error to Query: https://github.com/SeaQL/sea-orm/pull/750#pullrequestreview-1078933452 They should be mapped to Exec instead.

[mohs8421]

shortly regarding the name of errors: I think in UniqueConstraintError the Error suffix seems to be noisy in my opinion, as it is already within the DbErr enum. I would rather rename it to UniqueConstraintViolation as that is more speaking.

[billy1624]

I think UniqueConstraintError is only applicable to Exec, not Query ?

It should be applicable to Exec only. But I suspect update / insert operation with RETURNING is executed with query_one. So, the error might end up in DbErr::Query.

[Sculas]

Hey, any updates on this PR?

[tyt2y3]

Thank you for your patience