This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello,
During a migration I got an InvalidOperationException, leaving my database in a inconsistent and unrecoverable state. Without a backup, I'm unable to revert it to its original state, or run the migration again later (as some tables already exists, some don't). If the database engine allows it, is there a chance Lightspeed can wrap the migration in an transaction and rollback the migration when there is an error? Of course, some would prefer to leave the database in an inconsistent state (and restore the orginal database from a backup) rather than having a long running transaction. So it would make perfectly sense for it to be optional and not effect existing behaviour. Thanks, Werner PS I'm creating an post per issue I found today. If you prefer them all to be together, please let me know.
|
|
|
|
|
Post per issue is great -- it helps other customers to locate issues, requests and resolutions if they run into the same things. Thanks! On most databases, we run each migration inside a transaction. (We don't run a single transaction across the entire migration set, but this shouldn't be necessary, as the 'current version' table is updated as part of the same transaction as the schema changes, so if one migration fails, you should still be left in the consistent state resulting from the last successful migration, and should be able to re-run from there, or run the down migrations to get back to an even earlier state.) The exceptions are MySQL and VistaDB, where we found that schema changes within a transaction failed or even caused internal corruption. Are you on one of these databases? |
|
|
|
|
Yes, I was using MySQL 5.x on Amazon RDS. Given that limitation, validating the migration for obvious issues becomes rather important to me. Reporting any known database issues (like unique constraints on blob columns; or invalid names) will also help prevent this scenario. I can even use it in a test to ensure that manually created migrations will not cause problems. Thanks, Werner |
|
|
|
