-
-
Notifications
You must be signed in to change notification settings - Fork 297
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
Comments
This would be awesome! |
@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. |
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.
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 |
Hey everyone, that's correct! SQLite types is now non-lossy |
I'm pretty sure the CLI before generates Postgres columns as 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. |
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.
The text was updated successfully, but these errors were encountered: