Document migration failure condition & method for fixing

[katerd]

No description provided.

[Myster]

+1 I also can't find out why a migration failed. I just see 0 completed column in the db

[katerd]

Do you see any uFluent lines in the UmbracoTraceLog.txt file inside ~/App_Data/Logs/ ? It should start something like this:

2015-02-25 09:27:43,904 [19] DEBUG uFluent.Migrate.MigrationProcessor - uFluent.Migrate started
2015-02-25 09:27:43,919 [19] DEBUG uFluent.Migrate.Persistence.TableFactory - MigrationHistory table already exists.
2015-02-25 09:27:44,396 [19] DEBUG uFluent.Migrate.MigrationProcessor - Found 251 migrations
2015-02-25 09:27:44,396 [19] DEBUG uFluent.Migrate.MigrationProcessor - Starting migrations.
2015-02-25 09:27:44,402 [19] DEBUG uFluent.Migrate.Persistence.DatabaseUtil - HasMigrationExecuted for Initial is True

[Myster]

No, but now I do, and can't reproduce it not happening.

[tgriley]

You'll need to delete that row in the DB otherwise it wont attempt to run the migration again.

[Myster]

Is there an easier way to re-run a failed migration? as that workflow for my dev environment seems a bit clunky?

[tgriley]

Sorry for the late reply! I've been on holiday. If the migration failed you have to delete the row in the database for the migration. If it has ran 'successfully' but didn't do what you wanted you should do a db restore, but this is rare. We purposely made it slam on the brakes and rollback if anything isn't as expected to ensure nothing can have an adverse effect on our production environment, without this confidence automatic migrations would be a scary business!
Our workflow over the last 250+ migrations has been create db backup, run migration, then one of the following;

• DB indicates success & expected outcome - jobs a good'n, move on.
• DB indicates failure - check log, modify migration, delete row in migration history table.
• DB indicates success & unexpected outcome - workout what went wrong, do a db restore, modify migration and try again.

The latter has never happened anywhere other than our local dev environments. This is mainly because we follow this workflow, we are 100% confident the migrations that run in test/prod are exactly the same as the ones that executed successfully locally.

I totally agree that this adds a little extra effort in dev over a traditional approach, but we have found the advantages far outweigh the disadvantages. We do have plans in future to have a dash in the umbraco back end as you suggested but this will come after the fluent api is 'feature complete'.