In a flyway migration a FlyWayException can be throw according to differents cases : during a migration failure, if the given database url can not be found etc.
Everytime it's a FlyWayException with a JdbcSQLException as cause. But in my app I'd like to isolate these cases in order to provide differents behaviors.
Is there any way to do this ?
I can see that a JdbcSQLException contains a SQLState, maybe it can be a solution, but I don't know if it's the best one.
It is never good to parse out SQL exceptions as they may change from version to version of the database. I would submit a feature request to Flyway to have specific exceptions instead of one generic FlyWayException: https://github.com/flyway/flyway/issues.
Related
We've made use of environment specific migrations for things like seeding data, data correction, applying table grants. There are times when we'd like to take a copy of production, for example, and import it to another lower environment, either as a periodic refresh, or to start a new test environment. However, as expected, we end up with various failures like Detected applied migration not resolved locally and Detected resolved migration not applied to database. I see there are various flags (ignoreIgnoredMigrations, ignoreMissingMigrations and outOfOrder) to allow us to bypass these issues.
Are there best practices for handling scenarios like I described? Is there a way to run an environment specific migration that doesn't file an entry in the flyway_schema_history table? Other approaches to this issue that I haven't mentioned?
Thanks in advance for any insights.
We have used ignoreMissingMigrations as one approach around this issue.
Few customers reported than after the core data migration, their database entries result duplicated.
We opened the databases they sent us and indeed the entries are duplicated. We restore the backup and convert again the database, but we can't reproduce the issue in the office. Migration just works.
What could be the reason of this duplication? Is it related to the structure of the model, or something else?
It's a lightweight migration using model mappings. The core data databases are based on mysql.
thanks
After battling this for a while, the solution was pretty obvious for us. As it would only happen very occasionally so it was hard to find a repro (and even harder to find the reason!).
It seemed the app would sometimes crash mid-migration (for unknown reasons).
We are using deterministic file names for the destinationURL in -[NSMigrationManager migrateStoreFromURL:...] like appdata.sqlite-model_version_2.3. We weren't checking for the existence of the destination before migrating, and NSMigrationManager would copy directly into it regardless..so we'd get duplicates of every entity from the first (crashed) attempt, and singles of everything after that.
A few -[NSFileManager removeItemAtPath:error:] calls for the .sqlite, .sqlite-shm and .sqlite-wal before attempting migration to clean up any previous failed migration have solved the problem for us.
I'm using MigratorDotNet to manage Rails-style migrations for my web app. I have a workflow where, if I delete all the tables in the database, I can access an installation view that will run MigratorDotNet and create all the necessary tables.
This works locally. For some reason, when I upload my code to my Arvixe hosting, the migrations just never run. I get this odd error:
There is already an object named 'SchemaInfo' in the database.
This is odd because, prior to running migrations, I manually deleted all the tables in the database (to make sure it wasn't left over from a previous install).
My code essentially boils down to:
new Migrator.Migrator("SqlServer", connectionString.ToString(), migrationsAssembly).MigrateToLastVersion();
I've already verified by logging that the connection string is correct (production/hosting settings), and the assembly is correctly loaded (name and version).
Works locally, but not on Arvixe. How do I troubleshoot this?
This is a dark day.
It turns out (oddly) that the root cause was my hosting company used a schema other than dbo for my database. Because of this, the error message I saw (SchemaInfo already exists) was talking about their table.
My solution, unfortunately, was to rip out MigratorDotNet and go with FluentMigator instead. not only did this solve the problem, but it also gave me a more intelligible error message (one referring to the schema names).
While it doesn't seem possible to auto-set the schema, and while I need to switch the schema on my dev vs. production machine, it's still a solvable problem (and a better API, IMO). I googled, but did not find any way to change the default schema in migratordotnet.
I'm sorry for the issues that you were having. On shared hosting, unfortunately the only way that we may be able to change the schema is manually. If you are still looking for a solution that requires our assistance, please forward your ticket ID to qa .at. arvixe.com as well as arvand .at. arvixe.com and we can look into the best way to resolve this.
We have a .NET application that runs on Windows Azure and uses NHibernate to connect to a SQL Azure database. Sometimes it's necessary to add retry logic to handle transient failures in SQL Azure as described for example here -
http://social.technet.microsoft.com/wiki/contents/articles/retry-logic-for-transient-failures-in-sql-azure.aspx
Can someone point me to a way in doing this with NHibernate? Ideally I'd like to do this at the NHibernate level and not wrap every single call; I was able to do this for another ORM, .netTiers (http://nettiers.com) as I outline here -
http://blog.ehuna.org/2010/01/how_to_stop_getting_exceptions.html
I did search and found some answers that mention using a custom implementation of the IDbCommand interface -
Intercept SQL statements containing parameter values generated by NHibernate
But I'm not sure this works with NHibernate 3.2 and I'm looking for a clear example I could modify.
How could I make NHibernate retry calls to SQL Azure automatically? Let's say 3 retries, with 100ms wait between each - after the 3 retries, if still failing, we should throw the exception.
I've released a library that takes care of this:
https://github.com/robdmoore/NHibernate.SqlAzure
This is not a complete running example, but the files you need are here
https://github.com/craigvn/NHibernateRetryable
Maybe this can help you out:
http://www.objectreference.net/post/NHibernate-and-Execution-Plans.aspx. Here there is a class that you can download and play with it, with some overrides.
Also check this link as well: http://elliottjorgensen.com/nhibernate-api-ref/NHibernate.Driver/SqlClientDriver.html
I hope it helps in anyway, I'm going thru a similar situation.
Regards,
I'm trying to track down a problem on our test environment. Previously it was set to use InProc Session State Type, but I've added in the SQLServer type for one specific Web App. I did this because we use the SQLServer type in our production environment and I want our test env to match as closely as possible.
However, after changing it to SQLServer I do not get any errors when trying to store unserializable data in session like I would expect. It works just fine, even though I would think it shouldn't. I'm a relative newbie when it comes to configuring this, but from the various tutorials I googled, I thought I covered all the bases.
I was wondering if there's any code snippets to verify which session state type an application is actively using.
Thanks
Ok, found it by accessing:
System.Web.SessionState.HttpSessionState.Mode
Was also able to look at the tables in the ASPState database to see sessions being added/removed.
Apparently it was just the test code we were using that we expected to break that was not behaving as we expected..