Flyway operates at the schema level. What about objects at the database level, e.g. roles? It seems that these database-level objects are within the scope of what an application owns and could be considered part of its deployment. Is there any way to manage these things as part of a deployment performed with Flyway?
Flyway has no technical restriction on what you can do in .sql files. As long as the command can be expressed as a sql statement, you should be fine, regardless of whether if affects a specific schema or the entire DB.
The only schema-specific thing is the clean command.
Related
I have a requirement where if a table of a DB gets mistakenly dropped, we need it back, with or without the data. We already use Flyway for migration, is there any way we can achieve this using Flyway or otherwise?
I think you could hack a solution in place using callbacks (SQL or Java) but you've got to ask how can a table get deleted if you are using flyway to control migrations and amendments to your database in the first place.
This is fundamentally what flyway is intended to prevent as the following snippet from the flyway FAQ confirms and the solution may be to close the possibility of external amendments being applied in the first place.
Can I make structure changes to the DB outside of Flyway?
No. One of the prerequisites for being able to rely on the metadata in the database and having reliable migrations is that ALL database changes are made by Flyway. No exceptions. The price for this reliability is discipline. Ad hoc changes have no room here as they will literally sabotage your confidence. Even simple things like adding an index can trip over a migration if it has already been added manually before.
It seems not to be possible with versioned migrations, since they are applied only once, or with repeatable migrations, because they are reapplied only if check sum changes.
Another option - is to create a callback, which will run after migration.
For example, afterMigrate callback could do it, you just need to create a script named afterMigrate.sql in the location, used to load migrations. Now you just need to make a SQL-script to recreate some table if it not exists.
Some vendors support such an options, for example, with PostgreSQL you can use CREATE TABLE query with the IF NOT EXISTS option, to create a table only it doesn't exists.
I am starting to use the Liquibase SQL migration tool. I read the documentation but I'm not sure how the context could apply in my current situation.
I have 4 data centers with 2 environments each, one of production and another of tests.
Liquibase creates two tables with the log of the applied changes, DATABASECHANGELOG and DATABASECHANGELOGLOCK and all the scripts are applied in the same table, differentiating them from the context.
Is it possible to separate the list of production changes from the test or is it recommended to differentiate it with the context field?
For example:
Contexts: DC1_PROD, DC1_TEST, DC2_PROD, DC2_TEST, DC3_PROD,
DC3_TEST, DC4_PROD, DC4_TEST
Currently our functionality uses SQL Server Integration Services (SSIS) to replicate the tables with the changes therefore we do not use a centralized system.
Is Liquibase centralized and is it only necessary to have it in a single database?
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.
We are developing an application which uses multiple schemas to manage database objects.
I cannot see anyway of doing this with Liquibase.
I had to drop schemas manually and create them.
dropAll gradle task only drops objects in public schema.
Any help would be great.
Thanks for your time.
Liquibase can handle objects within multiple schemas and can also manage creating additional schemas as well.
When you connect to the database, Liquibase will create a DATABASECHANGELOG table in the default schema and that schema needs to exist. That table tracks which changeSets have executed, and anything that can be done through SQL can be done within your changeSets.
There are built-in tags for things like createTable, addColumn etc which will make changes in the default schema, but they all have tags such as tableSchemaName that can be used to target the object to a different schema.
If you want to make changes for which there are not built-in tags, you can always use the "sql" tag and specify whatever sql you want, such as create database additional_info
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.