Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SeaORM SQLite types are now non lossy #518

Open
jondot opened this issue Apr 3, 2024 · 5 comments
Open

SeaORM SQLite types are now non lossy #518

jondot opened this issue Apr 3, 2024 · 5 comments
Labels
enhancement New feature or request parked

Comments

@jondot
Copy link
Contributor

jondot commented Apr 3, 2024

See https://github.com/SeaQL/sea-query/pull/735/files

we can now attempt to have sqlite back as the primary “initial app” store, as it should now keep information about timestamp columns.

In the past the SQLite implementation lost type information as the migrations were applied and so when generating back entities we got compilation errors. This made us move to Postgres in development as a standard, and move SQLite into the shadows as “supported but..”.

We can now return SQLite to development configuration in favor of helping people get started more easily with less friction.

@jondot jondot added the enhancement New feature or request label Apr 3, 2024
@simonsan
Copy link

simonsan commented Apr 4, 2024

This would be awesome!

@Borderliner
Copy link
Contributor

@jondot I think SeaORM needs to reach v0.31.0 at least (v0.31.0-rc4 as of writing), the last release v0.30.7 doesn't include the aforementioned commit. Maybe there are other changes that loco needs to adapt to.

@jondot
Copy link
Contributor Author

jondot commented Apr 12, 2024

I've just finished testing this out, actually, the Sqlite variant works well, it required upgrading sea-orm-cli to rc3 as well, and types get discovered correctly.

Where I bumped into a wall is seamlessly moving between Postgres and Sqlite.

  • Postgres generated DateTimeWithTimezone
  • Sqlite generated DateTimeUtc

And since we have user-land code, these types could not co-exist. I played with everything a bit but had to take a guess, where even if I use sea-orm-cli it doesn't use the same bits the sea-orm core is using, which is why I was getting this difference. Since I am in no-mans-land (manually upgrading to rc versions all around), I'm OK with this, and I'll just park this issue and wait for sea-orm to advance a bit more with their versions before retrying.

/cc @billy1624

I'm optimistic this will eventually work and we'll return to co-driving both Sqlite and Postgres

Some references to capture time of writing:

https://github.com/SeaQL/sea-orm/blob/145bfa02a923722a12035c26a6195bc60580b351/src/driver/sqlx_sqlite.rs#L404
https://github.com/SeaQL/sea-orm/blob/145bfa02a923722a12035c26a6195bc60580b351/sea-orm-codegen/src/entity/column.rs#L62
https://github.com/SeaQL/sea-orm/blame/145bfa02a923722a12035c26a6195bc60580b351/src/driver/sqlx_postgres.rs#L694
#530

@billy1624
Copy link
Contributor

@schungx
Copy link

schungx commented Jun 26, 2024

Postgres generated DateTimeWithTimezone

I'm pretty sure the CLI before generates Postgres columns as DateTimeWithoutTimezone with the time being automatically converted into UTC (which incidentally matches SQLite's DateTimeUtc).

Not sure if the latest CLI still generates this data type since I have ditched the CLI in favor of editing the migration files myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request parked
Projects
None yet
Development

No branches or pull requests

5 participants