I have a jhipster project which i am deploying on prod using the command
java -jar project.jar
but during development I renamed some columns in some tables, when I am redeploying the code I am getting error of liquibase, I am told if I run the command below it should fix.
./mvnw liquibase:changelogsync
I do not have the code on prod but only jar file, please advise , what should I do to resolve it?
Sounds like you should spend a little time with the jHipster or Liquibase documentation to understand what it is doing. You didn't mention what the error was, but I am guessing it was probably something like "checksum for changeset with id xxxx changed from yyyy to zzzz." If you were able to run changelogsync in production, it would just mark all the changesets in your changelog as run by updating the checksum in the databasechangelog table on production, but your database tables will not have the correct columns.
Presumably you have run things in production and you have a table with some column - lets pretend it is named A for example. You say you renamed the column, lets pretend the new name is B. If you did that change by just changing the create table statement in the changelog, then if you run changelogsync in production what happens is that liquibase would think that the changeset to create the table and the column with name B has been run, but in fact it has not been run.
Instead, revert the changelog to what it was before, and rather than renaming the column by changing the changeset, create a new changeset that uses the liquibase renameColumn change type to rename the column.
Related
If there are rows in a migrations table in my database but the migration files are not in the code itself. Would that mean that the people before me who built the code before i took it over never pushed the migrations to the git repo? also if this is true would i have to create my own versions of the migrations and add them to the repo?
Correct, however I would check the packages you are using as well. Sometimes packages allow you to run migrations but they are not registered in your migrations directory. I always try to publish them to avoid situations like this. However if you look and don't see any of the missing tables, there are tools are out there that should help you make the migrations from an existing DB. You can take a look at this package for example: https://github.com/kitloong/laravel-migrations-generator
I try use flyway for migration. I find this option
spring.flyway.target= # Target version up to which migrations should
be considered.
But I need set version with which to start migration. For exmple I need start migration from V3_foo.sql
Can I do it?
Briefly why I need it. I have a database with data. No migration tools have been used before. Everything was done manually. Now I have created an init.sql and placed in it the creation of the entire base structure. Now, when adding changes, I will start the migration from version 2. And if you need to run on a new empty database - from version 1
Baseline is the flyway feature you need.
If your case, baseline your database with flyway.baselineVersion=2 will tell flyway that your database is already at the version 2. Any subsequent flyway migrate will only process migrations greater than 2.
Note: If previous migrations failed, it may be necessary to drop table flyway_schema_history first.
I have an existing database (version x), and I can generate ChangeLog file by using below command
mvn liquibase:generateChangeLog -Dliquibase.outputChangeLogFile=d:\output.xml
After that, I try to remove one table in database directly, How can I user Liquibase to rollback my database to version x ?
Once you have started using Liquibase, you should avoid making changes directly to the database.
Let's simplify the scenario to make it easier to describe. Say at version x your database has a single table called TABLE1 and nothing else. You run the generateChangeLog command, and you get a changelog that has a single changeset that says "create table TABLE1". When Liquibase creates that changeset, it gives it an id. After creating the changelog, you will then want to record in that database that the database and changelog are 'in sync' by running the liquibase changelogSync command - this creates a second table named DATABASECHANGELOG and adds a row to that table with the id of the changeset and some other information.
If you then manually delete the table, Liquibase doesn't 'know' that you have done this, so you would need to also manually let liquibase know that you had done that delete. You would do that by removing the row from the databasechangelog table. You could then re-create the table and get back to version x by running the liquibase update command.
I've always thought that if a migration applied with flywaydb is removed (both: entry from DB schema_version table and migration sql file) then application (written in spring framework with flyway in classpath) will crash at startup because of invalid checksums.
Actually (I tested it today) when both migration file and DB entry is removed application starts just fine, which I found a bit confusing.
How does flyway calculate the checksums? Is it based only on content of migration file being applied or previous migrations are also taken into account?
Also, is it safe to remove already applied migrations if both file and table entry is removed?
Many questions here. For your main question, this behavior is controlled by the ignoreMissingMigrations flag. See https://flywaydb.org/documentation/commandline/migrate
Checksums are calculated based on the content of the migrations files (ignoring line-endings due to Git CRLF transformations).
If both a migration file and its entry in the metadata table are removed Flyway doesn't know anything about it anymore. This however doesn't mean it is safe, as it may impact your ability to recreate your database schema later.
I have a local instance of a database that I recently created using DbContext.Database.Create(), so the __MigrationHistory table exists with an InitalCreate entry that matches the code at the moment.
Some code-based migrations exist in the Migrations folder, however. These will be run in our development and staging environments to bring those databases in line with the code. I don't need to apply them locally, however, since I created the database using the current code.
I now need to make a change to the model and create the corresponding migration. But when I run Add-Migration TestMigration, I get the following error
Unable to generate an explicit migration because the following explicit
migrations are pending:
[201203271113060_AddTableX,
201203290856574_AlterColumnY]
Apply the pending explicit migrations before attempting to generate
a new explicit migration.
What should I do in this case? I can't point the Add-Migration tool at another environment because it's not guaranteed that version matches what I have locally. I want a migration that matches only the changes I've made.
It seems I have a few options but none are ideal:
Delete the other migrations from the Migrations folder, run the Add-Migration command, upgrade the database, then restore the old migrations. This is simple but seems a bit hackish.
Revert to the version of the model in source control that the first migration was applied to, then build this and use it to create the database. Then get the latest version, apply all the migrations, then I'm ready to add my migration. This seems like a lot of effort!
Create the migration manually.
Does anyone have any suggestions about how to manage this?
We are planning to use a variant of your Option #1...
Our Standard Operating Procedure is to generate a SQL script for each migration (using the -script option of update-database), in order to have SQL scripts to be applied to end-user "production" databases by InstallShield (we plan to use EF update-database only for developer databases).
Thus, we have both the Migration .cs files and the corresponding .sql files for all migrations in our Migrations folder.
So rather than deleting the migrations from the Migrations folder (as you proposed in #1), we use SQL Mgmt Studio to manually apply just the parts of the .sql files that do the inserts into _MigrationHistory.
That brings the _MigrationHistory of the local database up-to-date with the changes that are already incorporated into that database.
But it's a kludge, and we're still looking for a better solution.
DadCat
What I've found works best is very simple: don't use DbContext.Database.Create() once you've enabled migrations. If you want to programmatically create a new database, use the migrations API instead.
var migrator = new DbMigrator(new Configuration());
migrator.Update();
Then you've got the full migration history and adding further migrations works just as expected.
You either need to run "update-database" from the package manager console to push your changes to the database OR you can delete the pending migration file ([201203271113060_AddTableX]) from your Migrations folder and then re-run "add-migration" to create a brand new migration based off of your edits.
I have encountered the same problem.
If you run
Update-database
and then run
Add-Migration YourMigrationName
This solves the problem
simply exclude the old migration file from the solution files.