Say I have three migration histories (call it init, m1 and m2). I use package manager to generate all the migration cs files and when I run my website on a live environment, it will update the database to the latest version m2.
Say unfortunately we found a major problem with migration m2 on live and whats to roll back, then what is the right way to do it?
I know that I call run this on my local machine:
Update-Database –TargetMigration: m1
However, that will only update my local version of the database. For production environment, should I do something like manually delete the migrationhistory record on live or delete the m2.cs migration file generated by entity framework and redeploy the site?
Related
I have a Hasura project with 3 environments: local, staging and prod
In order to develop locally with the latest data from PROD, I have written a script that dumps and restores PROD db locally
However, when trying to migrate the locally restored PROD db, I run into issues because the migration state is corrupted. Some migrations have been ran on PROD but they appear as not ran locally although it is exactly the same db.
When running hasura migrate status against PROD and local, I do see different results indeed
Howeve,r when inspecting the table hbd_catalog.schema_migrations on PROD and locally it contains exactly the same data...
What's even more confusing is that although PROD correctly marks some of my migrations as ran, their timestamp is not present in the migration table on PROD db...
Is there some other place that Hasura uses to keep track of these migrations?
What version of Hasura are you using? In Hasura 1.x the schema_migrations table was the location for tracking migrations but in in Hasura 2.x this got changed and they are now stored in the hdb_version table as a JSON blob in the cli_state column.
I had similar confusion after upgrading from 1.x to 2.x because the schema_migrations table is still left behind which made me thing it was still in use, but any records there are just vestigial and you can safely delete the table.
I changed a flyway script for error, and this brought my migrations to an error state (I have 5 script versions, but when I run my app it starts from the 4th, and get an error on 'reaction already exists').
I tried to use clean from flyway cli, but it didn't completely solve the problem... also, when I try pushing my branch to git, CI/CD pipeline will fail for the migration.
Since I'm in development environment, would it be a terrible idea to all delete migration scripts?
Would deleting all scripts allow me to 'start from scratch' in my development environment, or do I need to push the whole project again to avoid issues? (Project is not in production yet, I don't really need flyway migrations)
Depending on which flyway version you are using, one option is to go to the flyway_schema_history or schema_version table and just locate the row (corresponding to the failed script) and change the success column to true or 1. Then manually run the script (the correct one) against DB.
I am building an ASP.NET MVC EF app with code-first migrations and hosting it in Azure with Azure SQL DB. The first time I published this, it went fine. But since then my models changed, and my schema in the Azure DB is not getting updated to match. When I deploy, I do have "Execute Code First Migrations" checked. When that wouldn't work, I deleted my DB and then recreated it in the Azure portal, figuring that would trigger it getting updated. But then that didn't work, so I set AutomaticMigrationsEnabled = True in the migration Configuration. It is STILL not working, so currently my DB in Azure has none of my tables. HOW can I get the DB in Azure to be forced to update to match my models so the published site will work?? I did try looking for if there's a way to script the VS local DB to a Create query and execute that in SQL management studio, but couldn't find how to do that.
If you have made sure that you have selected update database in the publish setting, and the connection string is correctc and its still not updating. Maybe the following will help for you:
I sometimes get an issue like this, it is quite frustrating, My publish file is correct and my settings are set to allow SQL updates to occur during publishing. But sometimes the database hasn't been updated and I get a nice "backing context has changed" error, sometimes the culprit is the migration table that hasn't been updated. Unfortunately the only sure way to get your databases in sync is to check what migration history they are both at, by comparing [dbo].[__MigrationHistory]
If your published server is missing the latest migration history, then you can generate an SQL script of that by typing into the package manager console:
Update-Database -Script -TargetMigration [migration name]
'migration name' should be the name of the last migration that your published server had, visual studio will generate sql script that can be used to bring the database up to the latest migration from that target migration.
Sometimes (though very rarely, its only happened once or twice for me) the above doesn't work for whatever reason (usually because migration files have been deleted), if that is the case then its a good idea to script the whole database, and cherry pick the sql you need from that.
Update-Database -Script -SourceMigration:0
This will generate a script for every migration, you can then cherry pick based on the changes you've made. The 'latest' changes will be closer to the bottom of the file. every migrational change will start with an if check:
IF #CurrentMigration < '201710160826338_mymigration'
BEGIN
You can use this to pick the bits that you need, if you do pick the SQL be sure to include the update to the migration history. It will be at the end of the if block and look something like this:
INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])
VALUES (N'201710101645265_test', N'API.Core.Configuration', 'Some long checksum')
Including the migration history will ensure that visual studio doesn't have the problem again.
Hope this helps.
My current project has a few Flyway migrations in place that are used to import initial data into a database. This data is convenient especially for developers to be able to quickly setup the project. Production data is imported through some batch jobs and has a newer version.
Some of these migrations are quite big (~20MB) and so everytime the application starts, Flyway takes some time to calculate the checksum of the migrations. This also is a problem for integration tests as they also take longer because of this.
I consider this approach to be a misuse of Flyway, I think migration tools should be used mainly for structural data.
I want to remove those files from our application and rather use a configuration management tool (e.g. Vagrant, Puppet, Chef) to import test data on developer environments. However, I can't just delete the migration files from the application as Flyway will complain that a migration has been recorded in the database but is not present in the application migrations.
My first thinking was to create a new migration with a high-priority version number that will
Delete the test data
Delete the migration from the schema_version table
and then remove the migration scripts. This however does not work, Flyway still complains that the removed migration script is missing.
Is there a restriction that you cannot interact with the schema_version table in migrations?
What other options do I have? If at all possible I want to do this using Flyway and not manually.
Repair is your best bet. Empty those data migrations and run the repair command to have their checksums recalculated based on the empty files.
Does anyone have any best practices around deploying database changes in an EF 4.1 code-first solution? I know MS does not currently support database migrations for EF 4.1, but obviously people are going to need to do this from time to time.
Thanks
Once you deployed database to production you must do incremental changes. It means that before you deploy next version you must prepare two databases in your dev box:
Database with DB schema currently deployed in production - you should be able to get this from source control so always correctly label / tag your production releases
Database with new DB schema
Once you have two databases you can use some tool to make difference SQL script for you. I have experience with both:
Visual Studio 2010 Premium / Ultimate Database tools
Red Gate SQL Compare
These tools are for SQL server.
Once you have difference script you can test it on your dev box. Be aware that some more complicated changes cannot be created by difference script and require you to create custom migration script for example with storing data existing data in temporary tables while refactoring real table. Also if you use some new seed data in your new version you must add them manually into script or use Data Compare tools (also offered by both products).
After that you can plan outage of your production application, database backup and running upgrade script.