How to deal with sqlx dependency in model crate?

[luckysori]

With the extraction of a model crate with PR #1375 we have increased our awareness on what different parts of our codebase depend on. Particularly, we can now clearly see that our model depends on sqlx. Basically our choice of database for the application has leaked into our model. How should we handle this situation?

---

Relevant comment: #1375 (comment).

[thomaseizinger]

Some thoughts:

Completely removing the dependency will probably mean some more mapping logic in the database. If we want to pass our model types out of the DB functions, then we need to construct them in there. If the model types can't know about how they can be constructed from a DB row, then we need to construct other types first and then map into them.

Alternatively to removing the dependency, we can make sure to trim the feature-list down so that at least in theory, we only depend on the code that we need from sqlx (and potentially make it optional). In a way, this would be similar to a crate exposing a serde feature that optionally implements serde::Serialize and serde::Deserialize. This seems to be the Rust idiomatic way of dealing with this issue.

I am not sure how this will interact with compile-times in our workspace. We should take care that changing the feature flags of individual crates doesn't cause re-compilations because different crates need dependencies in different feature combinations. I think that if we always compile the entire workspace at once, it should gather all the required features upfront so I think that is a none issue.