I'm using grails database-migration to update my production db, but it' presenting a weird behaviour. I ran dbm-gorm-diff and it seems to work fine, but for some reason my prod db is getting updated without I use 'dbm-update' or put it to be executed when the war file is deployed.
What I realised so far is that it seems that any operation made on the prod environment is some how triggering an update on the db. And I couldn't figure out what.
did you set dataSource -> dbCreate to 'any other value'?
I highly doubt that this is what's happening; that would be a very serious bug, and it would have appeared before now, unless it's a very unusual combination of settings/state/db/etc. that triggers this.
If you can isolate this to a small and repeatable example please create a bug report at https://jira.grails.org/browse/GPDATABASEMIGRATION and I'll fix it ASAP.
Related
I have been building our grails app to AWS Elastic Beanstalk through Jenkins for awhile now without issue, jumping and building between branches for years. This became an issue, though, when adding the grails test suite into the build.
I set up a test database for jenkins to use itself and let grails populate all the table data on its own, it worked for several months until recently when I decided to deploy a branch that was around 6 months old to one of our development environments. As you can guess, a branch 6 months old was missing some columns that were in more recent releases, and hence in the database, so grails deleted those columns, and tested and deployed without issue.
The problem arose when I went to deploy a more recent branch to a different environment, and grails test-app started failing due to sql errors because the app was trying to use a column that didn't exist on that table.
I dug into it further and discovered in the logs that when grails should have been trying to update the tables because they already existed and just needed a column added, it was trying to insert the tables instead. Obviously this caused issue with the tables already existing and the database not being updated.
Does anyone have any knowledge on how to force grails test-app to update the database tables instead of try to insert them? This has never happened in the use of the app, so I know this is localized to an issue with the test-suite, but the documentation on it is kind of bad, especially for grails 2.3.11 so I can't find anything.
This ended up being due to the old branch that was deployed having a different dbCreate value for the test environment, so for some reason when it made it's changes with the dbCreate property of "update" then switched back to "create-drop" it no longer could drop the tables before re-adding them.
I'm starting with grails 3 using the Intelijdea IDE but I'm having a problem and it's that when I'm in development stage my app does not auto reload the changes made which I find a bit problematic ..
If anyone knows please help me with that problem.
I'm using grails 3.3.9 and had the same problem until I tried running my app with:
gradlew bootRun
And it worked!!
I am currently using grails 3.2.4 and auto reloading works fine. Only thing I noticed is that sometimes new methods don't get reloaded properly and will require a restart.
Maybe posting your exact grails and environment , version and details will help.
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.
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.