We are planning to migrate from Flyway to Liquibase.
Although Liquibase provides an option "generateChangeLog" that will output the xml changelog needed to create the database.
However we are looking to convert each of our script individually to xml , i.e each versioned script of flyway will become a versioned change set.
If done manually, it is going to be a tedious process, So we are looking forward to some automated solution for the same.
There is no way to migrate from flyway to liquibase but you can keep on one side flyway history in your souce files and begin with a diffChangeLog to initialize your liquibase from production environnement.
This way you have old history in your flyway scripts nd new history in liquibase
Related
Starting to learn Liquibase. I followed documentation, and watched tutorial videos. And I created MSSQL DB, did generateChangeLog, and changelog.xml got created. And did update on to target DB. Now I added one column, and want to capture it in next changeset. Which command should I run? Liquibase documenation says I should manually edit changelog.xml?
From your description, it sounds like you manually added a column to the source database and want to generate another changelog. This would not be the recommended way of using liquibase. The recommended best practice is to add a new changeset by manually editing the changelog.xml and using liquibase update to apply those changes.
Also, you can use liquibase diff or liquibase diff-changelog to generate new changesets of differences between the two databases.
We have some free training courses that will help available at Liquibase University
I am developing and have made changes to a db. Before I commit I have to add the change to my change sets. So I do liquibase --url="...;name=db_dev" diff but it asks me for reference parameters. However I do not want to compare the url db with another db. I want to compare the change sets (files) with a target db.
Is this possible?
I think you may be using Liquibase in a non-standard way.
One expected usage pattern is that you create the necessary schema changes by authoring a Liquibase "change set" (in either XML, JSON, or Liquibase structured SQL) and then using liquibase update to deploy that change to each of your database instances.
A second usage pattern has you make changes directly to a database using whatever database manipulation tool you prefer, and then using liquibase diffChangelog to append the corresponding change set to your changelog file. After making the change set, you then have to use the liquibase changelogsync command to populate the Liquibase DATABASECHANGELOG table on the database with the information that the new changeset has already been 'deployed' to the database. The second usage requires that you either:
compare two live databases (for example, you could compare a 'test' or 'staging' database to whichever database you manually changed)
create a database 'snapshot' before making the manual change, then make the change, and then compare the database to the snapshot. This page on the Liquibase blog describes how to use the liquibase snapshot command to take a snapshot, and how to use that snapshot as an 'offline database' to compare to.
This page in the Liquibase documentation has some more details on usage patterns when getting started with Liquibase.
I have an existing database and have used the generateChangeLog command line to create the initial changelog. This works fine :-)
But now I want the developers to use all the tools/processes they know/use already to develop the database and code and use a script to generate any incremental change sets as appropriate.
That is: do a diff against the current state of the developer's database (url/username/password in the properties file) using the current changelog (changeLogFile in the properties file) as the base reference.
There seems no easy way to do this - the best I've come up with is:
Create a new temporary database.
Use liquibase to initialise the temp database (to what is currently in the changelog) by overriding the connection url: liquibase --url=jdbc:mysql://localhost:3306/tempbase update
Use liquibase to generate a changeset in the changelog by diff'ing the two databases:
liquibase --referenceUrl=jdbc:mysql://localhost:3306/tempbase --referenceUsername=foo --referencePassword=baz diffChangeLog
Drop the temporary database.
Synchronise the changeset: liquibase changelogSync
but there must be a better way...
You are right that liquibase cannot compare a changelog file with a database. The only real option is to compare your developer database with an actual liquibase-managed database, or at least one temporarily created.
What I would suggest as the better way is to consider shifting the developers to author liquibase changeSets in the first place. It is different tooling than they may be used to, but it has the huge advantage that they will know that the change they wanted to make is the one that will make it all the way to production. Any diff-based process (such as using diffChangeLog) will usually guess right about what changed, but not always and those differences are often not noticed until into production.
Liquibase has various features such as formatted SQL changelogs that are designed to make the transition from developers working directly against their database to tracking changes through Liquibase because once that transition is made many things get much easier.
With Liquibase Pro you can create a snapshot file that accomplishes the same thing. And then use the snapshot file to compare your database updates.
https://www.liquibase.org/documentation/snapshot.html
I mention Pro because it takes care of stored logic comparisons as well.
I have a need to change the database schema . I'm planning to write Schema change and update scripts for tracking database changes and updating them. I followed
Versioning Databases – Change Scripts
for a start, I got a gist of what he is getting at however since I haven't worked much on SQL scripts before, a tutorial or something to start with would be good. I did some research on the web and came to know that most people use Automatic comparing tools to generate the script which I don't want to do for obvious reason that I won't learn the anything in the process.
I'm looking for some tutorials/links on How to write Change scripts and Update scripts ? Especially update scripts as I couln't find even a single script/pseudo-code on how to do update schema by comparing SchemaChangeLog table, connecting to the table using scripts...
Thanks in advance!
I would recommend using a database migration tool like liquibase.
Each change to the database is captured as a changeset and liquibase will automatically keep track of which changesets have been applied to the database, enabling updates and rollbacks.
I've read about how you can generate changelog.xml from an existing schema. That's fine, but I have existing systems that I don't want to touch, except to bring in new changes. I also have completely new systems which require all changes be applied.
So, I want to get liquibase to only perform migrations from changeset X when running on an existing system. I.e. that system's DB is at revision X-1 (but no liquibase sys tables), and I don't want any preceeding migrations applied.
Many thanks,
Pat
I would recommend a slightly different approach, as commented in this Liquibase forum thread
generate a changelog from your existing schema. The liquibase CLI can do that for you. I usually take the resulting XML and smooth it out a bit (group related changes into single changelogs, do vendor-specific cleanups and so on), but Liquibase does most of the legwork.
run that changelog against the existing database (changelogSync command), but only marking it as applied (without actually modifying the schema).
use liquibase for applying new changes from that point on.
I think the easiest would be to execute the initial setup on an empty database at first and export the entry(ies) liquibase does insert into the DATABASECHANGELOG table. Then I'd export these entries and insert them manually into one of the target databases into their DATABASECHANGELOG table, so liquibase does not execute the "change" there again.
Of course I'd test all that with test dumps on a test machine... :)