I'm looking to introduce the Grails DBMigrations plugin into an existing application.
My understanding is that after installation the first thing to do is to create the initial changelog.groovy which I've done with the command
dbm-generate-gorm-changelog changelog.groovy
This does create the file correctly, and contains all the necessary commands to recreate the database schema.
Secondly my understanding is I should then issue the command dbm-changelog-sync to indicate that the changelog script has been executed.
What should happen if I then issue the command dbm-gorm-diff ?
At this point I'm expecting to see an empty changelist... because the initial schema was created, committed and no changes have been made to any domains, however I see a bunch of entries.. for modifying column types and a few index creation entries.
Any advice appreciated, I've reached this point because I want to update the database in a production env database, and don't want to start writing manual tests and SQL in bootstrap to update the DB as this will surely lead ultimately to a maintenance migraine. Using DBMigrations appears to be the way forward but either I don't understand it, or it's buggy and don't want to risk using it.
And as others have commented in other threads, I'm restarting the grails console between issuing commands to avoid reloading problems.
Thanks
Dave,
The important thing to remember about the migrations plugin is that is output from dbm-gorm-diff is not meant to be taken as gospel. It is simply meant as a way to hopefully save you from some typing. Anything generated automatically from the plugin should be reviewed and analyzed to determine that it is what you desire.
Related
I have gotten myself into an odd Groundhog Day scenario with an MVC application of mine.
Unless I apply my workaround (Later in this question) each time I debug the application I'm presented with this error:
The model backing the 'UsersContext' context has changed since the
database was created. Consider using Code First Migrations to update
the database (http://go.microsoft.com/fwlink/?LinkId=238269).
I have not changed the model.
My workaround workflow is:
Add-Migration WHATEVERNAME (Makes a blank migration)
Delete this migration.
Run: Update-Database
Recompile & Run (Now without error)
Notes:
The __MigrationHistory hashes of the latest migration match in both script and in the database.
I have my MVC application & EF project as separate projects.
I have tried creating an -IgnoreChanges migration, to see if applying this would mitigate the issue. It did not.
This is quite frustrating, how would I solve this issue permanently?
Note: Automatic migrations are not suitable for my scenario.
Well, it's almost impossible to understand what's wrong without knowing much more detail. So all I can do is give you some clues of what you could try.
Stopping and restarting the app should not cause the DB to get out of date. Is it only when debugging? Have you tried running the app without debugging? Then recycle the app pool and running the app again.
Do you have any weird post-build step that will overwrite some DLL in your "bin" folder?
Is your app doing something that changes the database schema, thereby invalidating it when you next start up? Run SQL profiler to check what is happening to the DB when your app starts up.
Migrate back to the first version of your schema, and then back again (backup your DB first):
update-database -TargetMigration:0 -verbose
then
update-database -verbose
Temporarily comment out the bulk of your app to try to isolate the cause.
Create a brand new app with EF configured in the same way, copy the connection string and see if it happens for that. If not, then there must be something different. If yes, then show us your EF settings.
Hopefully something here that could give you an idea at least. Good luck!
Enabling migrations sets up the whole migration system. But to enable automatic migrations you have to include -EnableAutomaticMigrations which simply adds the line
AutomaticMigrationsEnabled = true;
into the newly generated Configurations.cs file.
In conjunction with the database initializer, development turnaround is more streamlined because you no longer have to type add-migration and update-database every time you make a change. That will happen automatically now. However, that’s not enough, if you want column removals you have to also perform step 3, where automatic data loss is supported.
When you are ready to release software (internally or externally) where you need strict version control and to upgrade databases on site, you should remove automatic migrations and add a manual migration point.
This can happen when updating to EF6 which made schema changes to the _MigrationHistory table (https://msdn.microsoft.com/en-us/data/jj591621)
The EF6 version has a new column ContextKey so the migration is probably trying to add that column.
I'm guessing if you scaffold it will just be making those changes - or perhaps there's something you changed a long time ago that wasn't 'picked up' yet for some reason.
OR if you just don't want to deal with it right now you can disable migrations temporarily.
System.Data.Entity.Database.SetInitializer<UsersContext>(null);
I am using Grails 2.3.5 with database migration plugin in new project for understand how it is working. But sometimes dbm-gorm-diff provide empty changelog file,even changes is there.
For example,
i have the person domain class with out any properties.
When initially creating change log, it will create 2 fields id and version in change log.
After that, added 2fields name,age into that person class. then did dbm-update and dbm-gorm-diff that give like following.
databaseChangeLog = {
}
Sometimes gives the changes. some times is not working. Please help me. Why it is working like that. Sorry for bad english.
Using the following tutorial works for me. Make sure you remove dbCreate from your DataSource.groovy. According to the tutorial the workflow is as follows:
Setup
Remove dbCreate from DataSource.groovy
Initially run grails dbm-generate-gorm-changelog changelog.groovy
Sync the changelog with your db by running grails dbm-changelog-sync
Changing domain
Change domain class
Run grails dbm-gorm-diff <your-filename>.groovy --add
Run grails dbm-changelog-sync
Hope this helps
I have spent some time searching for the answer to this same issue.
Caveat: I am using the Grails interactive shell to issue commands, including the dbm-* commands.
By brute force alone, I have come to the conclusion that the domain classes are not reliably reloading. To get consistent results (especially with the generation of new changeLog files), any time I modify a domain class, I stop and restart the Grails interactive shell before calling dbm-gorm-diff. I've tried issuing other commands like clean, compile, package and refresh-dependencies and they just aren't working, and the -reloading flag at the start up of the Grails interactive shell doesn't seem to make any difference either.
Restarting the Grails interactive shell, however, does seem to work reliably, thought it galls me to do so :)
Those who do not use the interactive shell should not be having this problem since the domain classes are loaded with every command call.
This blog has detailed step by step explanation, specially Migrating old databases section helped us in migrating successfully.
I have a MVC 3 project were I use code based migrations together mith automatic migrations(this works).
When I install this project on a new server the database is created by CreateDatabaseIfNotExist initializer, cause I´m using the seed method of this. After executing this I have a __MigrationHistory table with one entry. The model hash of this entry is exactly the same like the last one from my developement server. On my development server I have an entry for each of my code based migration in the __MigrationHistory table.
Now the problem is that when I try to run the migrations on the new server, I expected them to say to me "nothing to do, cause model hash is same", but instead of this the migrations seems to look only for the MigrationId in the database and try to execute every migration whose MigrationId is missing. Of course this leads to Exceptions, cause the migration tries to add database structures already there.
I think this should be a very common scenario, so is there a kind of workaround for this? My workaround for the moment is to copy all contents from the __MigrationHistory of the development system to the new server, but this is very tricky, due to the dealing with the modelhash as varbinary. Is there a better solution or did I understand some logical things wrong?
I'm considering using Ruby on Rails for my next project. Understanding the deployment of a rails website is easy enough to understand (sounds like I'll be using Phusion Passenger)
But now I'm trying to figure out the database. I see a lot about "database migrations", which allow me to update the database using ruby code. I also see that I'm allowed to create both an up and down variant of these migrations.
However, I can only fathom how this works cleanly in a single direction. Imagine if I suddenly say "The color column cannot be null". So, the up will make it required and give all NULL entries a default value. But what will the down do? If you care about it being identical to how it started, you can't just set the default values back to NULL.
This doesn't really matter much for releases to production. That will likely just be done in a single direction (in the up direction). However, I want to use Gerrit for code reviews as well as setting up a bot to run a build before allowing check-ins...
So how could that work? From one code review to the next, the build server will check out the new set of code, and run the migrations? But when this happens, it won't even retain the migration code from before, so how could it run the down steps? As an simpler example, I do not see how I could check out an old version of the code and "db migrate" backwards.
Yes, you can't check out an old version of the code and then run a down migration from a newer version of the code. You would need to run the down migration before rolling back to the older code.
There are many, many cases where a down migration is just not practical or possible. That's not necessarily a bad thing. It just means that you have defined a 'point of no return', where you won't be able to restore your database to an earlier state.
Migrations like creating a table or adding a column are easily reversed by simply destroying that table or removing that column. However, if you are doing something more complex, such as adding default values or moving data around, then you can tell Rails that it's not possible to reverse this migration:
def down
raise ActiveRecord::IrreversibleMigration
end
I would recommend that Gerrit should never assume anything about the database. It should start with a fresh database each time a new version is deployed, and run db:migrate to run all your migrations. You can use gems like factory_girl to populate your app with demo data for testing purposes.
I'm considering using Entity Framework 4.3 migrations in a production site. The following is my concern:
If the migration fails for whatever reason, I want all statements
rolled back and the site placed in a down state so no users can use
the site while I try to fix the problem. The only thing is I can't
fall back to executing the scripts by hand against the database since
migration files are compiled in the assembly. I could keep track of
both migration files and sql script files separately but at that point why use
migrations at all.
At work, script files are stored in a SQL folder (that no one can browse to) on the site. Previously run script files are registered in the database. When new script files appear in the folder (and aren't in the database), if a user is an admin, they'll be redirected to a DB portal, else get a site-down-for-maintenance. If we try and fail to execute any scripts from the portal, we grab the new scripts and try to run them manual inside of express studio. This has worked for over a decade. I'm only exploring migrations to see if a better way has arrived. It doesn't feel like it. Please let me know if there's a better way and if it's not Migrations, what is it.
I would definitely not use automatic migrations in a production environment. In fact, I'm too much of a control freak to use automatic migrations at all. I prefer code based migrations to ensure that all databases (developers' own personal, test environment, production) have gone through exactly the same update sequence.
Using code-based migrations where each migration step gets a name, a separate migration script can be generated for use when lifting test and prod environments. Preferably it should be run on a copy of the database to validate before running on the real prod environment.
Added Later
To prevent EF Migrations from doing anything automatic at all, a custom initializer strategy can be used. See my blog or the Deploying EF Code First Apps to Production Database Stack Overflow question.