Replies: 4 comments 3 replies
-
Can you reconstruct which migration may have been responsible for this? The one from 6 to 7? I'm very surprised about this since none of your migrations actually delete any tables or columns. Can you reproduce the issue by e.g. installing your app at an older version on your devices and then replaying the update?
That's because the command is not aware of schemas previously exported - but if you want to switch to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for the quick reply, really appreciate it! What I tried after your messageI realised the command just puts the new files into dart run drift_dev make-migrationsAfter that, the generator picked up all versions (v1-v7) and produced a complete The big change in v6 was that I enabled store_date_time_values_as_text: truein Before moving the JSONs I also tried deleting everything in rm lib/.../drift_schemas/drift_schema_v*.json
dart run drift_dev schema dump lib/.../database.dart lib/.../drift_schemas/Tests passed (of course) but as you said this offers zero protection for older migrations, so I reverted that.
Any guidance on how to “re-canonise” the schema files (or whether I should roll back the date-time change and re-introduce it properly) would be great. I’m happy to redo the migration in the cleanest way, just want to avoid yet another data loss incident for users. Thanks again for your help! |
Beta Was this translation helpful? Give feedback.
-
|
I'm facing an issue when switching the store_date_time_values_as_text option from false to true in my migration tests with existing migrations. I'm not sure if this problem is the same as the one discussed here. My database schema version is 3. Initially, I set store_date_time_values_as_text to false. During the migration from version 1 to version 2, I added a new table with a DATETIME column. Then, in the migration from version 2 to version 3, I changed the store_date_time_values_as_text option to true. However, when I run the migration tests, I encounter the following error when the migration from version 1 to version 2: Did I miss something in the process? I followed the guide at this link, but I am still encountering the error. Here is my configuration, and I used the instructions from this migration guide to perform the migration. drift: 2.26.1 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @simolus3 I hit two sneaky migration traps when flipping
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I’ve been using Drift since version 2.9.0. Recently, I released a new version of the app which included many changes. Unfortunately, all users lost their data, resulting in a lot of negative feedback. I’ve tried to follow the Drift documentation carefully, but I’m not sure where I went wrong.
For every change to the database, I followed these steps:
1.
After making any changes to the database, I incremented the
schemaVersionand ran:2.
Each time the local database schema changed, I ran:
3.
After exporting all schema versions, I used this command to generate code to help with step-by-step migrations:
I also noticed that Drift now supports a new command for migrations:
When I ran it, a new folder was created at the root level containing only the latest migration, which confused me.
Here is my current folder structure, which I believe is correct:
Here is my code:
database.dart :
connection/connection.dart :
connection/native.dart :
connection/unsupported.dart :
connection/web.dart :
lib/build.yaml
pubspec.yaml
Could you please review my code and let me know if I’ve done anything wrong? Also, suggest any improvements to the database functions and settings if need it.
Also, as I mentioned, when I run the command
dart run drift_dev make-migrationsfor a new migration, it creates it in thelibfolder. However, my previous migrations were located in thedatabasefolder, and this new one only includes the final step as step 7.Beta Was this translation helpful? Give feedback.
All reactions