Introducing the error `UniqueConstraintViolation` as a separate kind.

[mohs8421]

Interpreting errors now is usually no longer independent of the database, so the error handling functions in sqlx_common.rs have to be split up. Since the interpretation depends on the backend, I provided a method there, which redirects to the driver implementations. I dropped the mentioned functions in sqlx_common, to avoid anyone relying on these, as that would no longer be valid without knowing the db context.

[mohs8421]

I decided for this route to not loose any information on the original sqlx error in case it is not a database error. But honestly I'm not even sure that this would happen, so feel free to change that if it holds to that condition.

[billy1624]

Calling as_database_error only take a reference thus you won't lose the original error. You can try it :)

[mohs8421]

@billy1624 it is a little more complicated than that. I want to consume the error, if it is a database_error, but not in other cases. Now as_database_error will never consume it, but into_database_error will always consume it, so I have to handle it differently.

Besides, in the end I still would have a match for both scenarios, which does not make a difference to me, so nothing to win there.

[Sculas]

Does this also account for mock databases?

[tyt2y3]

Hey thank you for your effort. I have a slightly different idea to the implementation, might need @billy1624 's help indeed.

[mohs8421]

Hey thank you for your effort. I have a slightly different idea to the implementation, might need @billy1624 's help indeed.

would you care to elaborate, what your idea is?

[Sculas]

@tyt2y3 looks like you deleting the branch closed the PR. Maybe target the PR to master and reopen?

[billy1624]

Hey thank you for your effort. I have a slightly different idea to the implementation, might need @billy1624 's help indeed.

Hey @tyt2y3, what's your plan in mind?

[tyt2y3]

I am thinking of adding a method to RuntimeErr:

impl RuntimeErr {
    pub fn sql_err(&self) -> SqlError;
}

#[non_exhaustive]
enum SqlError {
UniqueConstraintViolation,
ForeignKeyConstraintViolation,
}

So we always store the SqlxError and provide a helper method to extract that information.

I think these are very different from say UnpackInsertId, where the SQL executed successfully, but an error is detected in SeaORM.

Another PR is definitely welcomed.

[mohs8421]

The important question here is: What would the user of sea-orm want in the case of an error? The users usually want to know, whether they can circumvent this error somehow (e.g. retry after a deadlock) or have to fix an error in their system, or if it is a wrong usage, that needs to be forwarded to the user.

I don't see how moving the error kind one level down behind another method, that users would have to know would help here. I would agree on moving these kinds into RuntimeErr, I even considered that thought myself. Might be easier to mock the error case.

[tyt2y3]

The reasoning is:

1. to preserve the original SQLx error
2. to construct a hierarchical namespace. With #[non_exhaustive], we can add more variants to SqlError later.
3. the error is lazily parsed

[mohs8421]

regarding

1. the original SQLx error is preserved anyway using the #[source] tag.
2. that is an acceptable reason.
3. that is only possible with the knowledge of the database in use, so lazy parsing is harder to achieve.

[tyt2y3]

Actually, I am not against downcasting, so we can try downcasting to MySqlErr, and that we will be able to know which database it is originated from.