I'm using EF Core and code migrations. It's my understanding that the snapshot file is supposed to be the "target database" to build future migration files off of.
Situation:
1) I did an add-migration to create a migration after some changes. This updated the modelsnapshot which I guess is the expected behavior.
2) I then realized I realized I mis-typed one of my fields. Instead of a string it was supposed to be a byte[]
3) I made the changes to the classes
4) I did add-migration again.
Now the DataSnapshot seems to be out of sync because the new add-migration does not include this type file change.
It doesn't seem like I can do a remove-migration because no migration was actually applied to any database.
I know in EF6, this was a fine way to do it because it always targeted an actual database for the changes and not this snapshot file. So just deleting the change file and remaking the change file was good enough.
This is the second time I've had to make some change to a migration file after realizing there was an issue (without actually running the update against anything) and both times were just incredible pains to try to fix the issue without wiping out all my previous migrations and starting over.
My question is how do I handle this now? Should I be deleting both the change file and the snapshot file every time I do backtrack on an add migration?
I'm really concerned that I'm missing something here because now I have to make sure that not only is the change file correct but also the current snapshot is correct as well and if that snapshot ever goes out of sync, then I have to go and manually update it to
Probably have solved this by now, but I just ran into this.
Not sure if this is exactly the same issue, but this is how I understand it.
update-database is a DB action and updates your DB to current version or target migration.
remove-migration is an EF action and updates your migration stack and updates your snapshot.
To downversion I had to update database then remove migration down to the intended target.
At this point adding a new migration gave me the expected set of changes, where as before it was giving me none.
This appeared to do what I expected from EF doing update-database and update-database -target
The only thing I think you can actually do wrong in this case is delete your migration files before doing the update, because the down steps are indicated in the migration files, so it wont be able to complete this step if you remove the files. If you have the files, you can freely target migrations to set your current DB state.
I believe the confusing part is that the snapshot was previously used on every migration, where as now there's one snapshot for "last migration"
Related
I just started orocommerce. I was creating a migration to add a field to the customer table. But whenever I try to dry run the migration I get a long list of migrations to run alongside the migration I created. And even after running the oro:migration:load many times these still show up.
List of migrations:
Oro\Bundle\EntityExtendBundle\Migration\LoadEntityConfigStateMigration
Oro\Bundle\MigrationBundle\Migration\UpdateBundleVersionMigration
Oro\Bundle\CheckoutBundle\Migrations\Schema\RemoveWorkflowFieldsMigration
Oro\Bundle\EntityExtendBundle\Migration\RefreshExtendCacheMigration
Oro\Bundle\EntityConfigBundle\Migration\UpdateEntityConfigMigration
Oro\Bundle\EntitySerializedFieldsBundle\Migration\SerializedDataMigration
Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendConfigMigration
Oro\Bundle\ActivityContactBundle\Migration\ActivityContactMigration
Oro\Bundle\ActivityListBundle\Migration\ActivityListMigration
Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendIndicesMigration
Oro\Bundle\OrganizationProBundle\Migrations\Schema\UpdateConfigsWithOrganizationMigration
Oro\Bundle\EntityConfigBundle\Migration\WarmUpEntityConfigCacheMigration
Oro\Bundle\ScopeBundle\Migration\Schema\UpdateScopeRowHashColumn
how do I fix this problem?
These migrations run every time intentionally to warm up some caches and do additional changes that may be needed before and after schema changes. You don’t need to fix anything here.
I use Flyway-core 5.1.4 version in my Java Spring boot project.
I know if I change something in R_ migraion I will get new record in flyway_schema_history table with new checksum. But I got random apply of repeatable migrations in the end of my flyway_schema_history table without any changes in R- migration, even without additing any V_ migrations and without re compiling or redeploying of my project.
How is it possible ?
And it seems to me that I got old version of my R- migration, something like overriding.
Do you see the checksum of the repeatable migration change each time it is run? You should do, as that's the trigger for it to be re-run; and if that is happening then it suggests something is changing the file, perhaps only whitespace but that is enough.
While studying and following along with the migration section, I had done the initial, then followed it up with the next two migrations as shown. On the last migration an error of the "course" is already in the database. Exact error "There is already an object named 'Course' in the database." I removed all migrations and re-did the shown migrations, each time ending with the same error.
Why does this type of error occur? A
nd how to completely remove all migrations (my migration folder was blank) so that one can move forward with the next migration. Am I missing something?
This is potentially a big topic to fit into a single answer. I will try to give you an overview, background and advice. Further reading will be required to get a full understanding of how Entity Framework should be utilised. I will mostly cover Migrations, as that is the main thrust of your question.
OVERVIEW
Entity Framework Migrations offer the ability to rollback the changes made to a database, back to the schema of the database that is contained in a specified Migration; e.g. to undo schema changes by returning the database to a previous schema - and also to return it to its original state.
Note that data loss can occur when applying or rolling back Migrations, but in your scenario this is possibly not important.
The command to return a database to a specific Migration is:
Update-Database -TargetMigration:"migration_name"
The command to return to the initial, original state of the database is:
Update-Database –TargetMigration: $InitialDatabase
Entity Framework also has the optional concepts of Database Initialization and Initialization Strategies, that allow a developer to specify that the database should only be created once, or dropped and created each time an application is run, depending if their Code First model has changed. Please refer to these tutorials for more in depth coverage of Database Initialization.
As you say you have no Migration files in your Migrations folder, let us continue...
BACKGROUND
When you first run the Enable-Migrationscommand, it will create a class that is used for managing subsequent application of Migrations.
When you generate your first Migration, by executing, for example:
Add-Migration InitialCreate
This will create an InitialCreate file within your Migrations folder, that contains the initial schema, according to your class model that will be persisted by Entity Framework. The example name InitialCreate is optional and can be anything you wish - it is simply a label that can be referred to later.
Subsequently, when you issue an Add-Migration command, further Migrations are created to apply schema changes related to your classes; they will be added to your Migrations folder, but, not yet applied to the database.
The Migrations can then be applied to your database by issuing the Update-Database command. If executed without parameters, the database schema is updated to the schema defined by the latest Migration.
If you are following the Contoso tutorial correctly, you should have several Migrations, one of which contains the word 'Initial' in its name, as part of the convention.
ADVICE
If you do not see these, it is likely that you have not initialised Migrations, by issuing the command Enable-Migrations.
After executing Update-Database for the first time, verify this also creates a database table named __MigrationHistory - this tracks the schema versions and Migrations that have been applied.
You have possibly applied Migrations in an incorrect order, and it now does not match your class structure, or, is out of sync with the schema tracking within the database.
In your current circumstances, as you are following a tutorial, it is probably best to delete your database, and recreate it following the steps outlined by Microsoft, paying special attention to the output from Enable-Migrations, Add-Migration and Update-Database commands, verifying the database schema at each step.
REFERENCE
For reference, the overview of how Migrations should be utilised, can be found on MSDN here.
A walkthrough of using Migrations with MVC can be found here
So while building a new database using our database migration scripts written in a springboot flyway project, we realized we made some mistakes.
Some old scripts need to be changed to ensure that we do not face these issues when we make a new database schema again. These issues are mostly related - an info table was not populated with entries in the project and there are scripts that refer to the data in the migration project -- this data does not exist because we never included a script to include data.
How can we correct this project - the only way I can think of is to correct scripts such that all inserts are replaced by - insert if not exists or replace create statements by create if not exists.
and then delete all entries in schema version and re-run this on all the database which are using this schema.
I cannot go back and correct my script because then the migration project will fail because of checksum issues.
You are rigth, if this project and the scripts are running in some existing projects you can not modify them because the checksum would fail.
Then the cleanest way I can think would be add a file called "DB-GENERAL-FIXES" or something like that, where you can add all SQL validations to restore the DB to a stable status. For the new implementations will be extra work first build it wrongly and then clean it, but if you are sharing the same code in production right now...is the best option
OUR SYSTEM
We are trying to put migrations as .sql files under version control. Developers would write a VN__*.sql file, commit to version control and a job that runs every 5 minutes would automatically migrate to a Dev and Test database. Once the change proved to not cause problems, someone else would run a manual job to run the migration on Production.
MY PROBLEM:
I had a demo migration that created a few tables. I checked V4__DemoTables.sql into version control on my PC.
On our Linux box a job that runs every 5 minutes extracted the new file from version control, then ran the flyway.sh file. It detected the file and executed it.
But the .sql file had a typo. And we are using Neteeza which has problems with flyway automatically wrapping a migration in a BEGIN TRAN ... END TRAN. So the migration created 2 tables, then aborted before the third.
No problem I thought. I dropped the 2 tables that the .sql file did create. Checked V4__ out of version control, fixed the typo and re-submitted it.
Five minutes later the update was extracted but flyway complains that the checksum does not match. So it will NOT run the updated V4__DemoTables.sql file.
How do I get flyway to accept the updated file and update the checksum in the SCHEMA_VERSION file in case of a typo?
Reading the docs it seems like the developers suggest I should have created a new V4_1_DemoTables.sql file with the fix's. But this would have collided with the commands in the V4__ file so this seemed wrong.
So here is what the docs imply I need to do:
Leave V4__ as a 'successful' migration according to the
SCHEMA_VERSION table.
Create V4_1_ to delete the tables that were created before the typo
line in V4__.
Create V4_2_ which has the typo fix from the original file to do all
the real work.
Is this correct?
If the migration completes successfully, but some of the db objects are not quite right yet (typo in column name, ...), do as you said and push a follow-up script that fixes it (rename column, ...).
If the migration fails, and it didn't run on a DB with DDL transaction, the DB must be cleaned manually. This means:
Reverting the effects of the migration on the DB
Removing the version from the SCHEMA_VERSION table and marking the previous one as current
This second step will be automated in the future with the introduction of the flyway.repair() command.