search

dev-mag / uFluent

Code-first migrations for Umbraco
http://our.umbraco.org/projects/developer-tools/ufluent
Apache License 2.0
16 stars 4 forks source link

Document migration failure condition & method for fixing #1

Open katerd opened 9 years ago

Myster commented 9 years ago

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

katerd commented 9 years ago

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 commented 9 years ago

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

tgriley commented 9 years ago

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

Myster commented 9 years ago

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

tgriley commented 9 years ago

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;

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'.