feat: MySQL support #75
Conversation
m4tx
force-pushed
the
mysql
branch
3 times, most recently
from
e8c1b90
to
5226570
Compare
Codecov ReportAttention: Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
🚨 Try these New Features:
|
flareon/src/auth.rs
Outdated
| @@ -6,6 +6,7 @@ | |||
| //! | |||
| //! For the default way to store users in the database, see the [`db`] module. | |||
|
|
|||
| #[cfg(any(feature = "sqlite", feature = "postgres", feature = "mysql"))] | |||
There was a problem hiding this comment.
Is there a way to create an alias for it? We will repeat that in many places in the code.
One idea I have is to create an empty __db feature that each database feature would include as well, and then we could just check for it.
There was a problem hiding this comment.
Yeah, that's one way to resolve it. Except that I think it should actually just be named db (sadly there's no concept of "private" feature flags in Cargo as of now and special naming doesn't change much about this) and we should generate a compilation error in build.rs if db is enabled, but none of sqlite, postgres, and mysql are (if we don't do that, then seaquery-binder will fail to compile as far as I remember). But generally I think this is a decent idea
| Timestamp, | ||
| TimestampWithTimeZone, | ||
| DateTimeWithTimeZone, |
There was a problem hiding this comment.
There seems to be no consensus on what does "datetime"/"timestamp" mean in database engines:
- SQLite doesn't have a concept of a date(time), you just store it as text
- Postgres doesn't have a dedicated datetime field; instead it just has timestamp with a wide range of possible values
- MySQL has both: datetime is anything between year 1000 and 9999, while timestamp is 32-bit unix timestamp, so it's susceptible to Y2038 problem. MariaDB is slightly better in this regard, but it only supports timestamps with years up to 2106.
I thought it might be surprising for users who might want to store arbitrary chrono::DateTime objects and see them failing if they don't fall between 1970 and 2038. So I changed the naming so that it's clear it's not a timestamp, and we might eventually add a separate "timestamp" type in the future. For now, I just want to make sure that whatever (sensible) value the users might want to store, will work.
| let test_database_name = format!("test_flareon__{}", test_name); | ||
| let test_database_name = format!("test_flareon__{test_name}"); | ||
| database | ||
| .raw(&format!("DROP DATABASE IF EXISTS {}", test_database_name)) | ||
| .raw(&format!("DROP DATABASE IF EXISTS {test_database_name}")) | ||
| .await?; | ||
| database | ||
| .raw(&format!("CREATE DATABASE {}", test_database_name)) | ||
| .raw(&format!("CREATE DATABASE {test_database_name}")) |
There was a problem hiding this comment.
No one can hide from Clippy's watchful eyes lol
This also deduplicates the database code and adds feature flags that can enable and disable the database backends (or remove the ORM altogether). This commit also adds a cargo hack step to the CI that checks if the project can be compiled using any subset of the features.
This also deduplicates the database code and adds feature flags that can enable and disable the database backends (or remove the ORM altogether).
This commit also adds a cargo hack step to the CI that checks if the project can be compiled using any subset of the features.