I'm trying to use multiple contexts support in Liquibase and I can't achieve the result. My changeset in SQL format looks as follows
--changeset bkolasa:1 context:new-db and !edb dbms:postgresql
Then when I execute command
java -jar liquibase.jar --contexts=new-db,edb --driver=org.postgresql.Driver --url=jdbc:postgresql://example.com:5432/liqtest?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory --username=liqtest --password=liqtest --changeLogFile=mychangelog.sql update
the changeset is still loaded.
My version of Liquibase is 3.2.2.
-- changeset istepniak:db-1.14.1 context:dev and test
This works for me
–context=dev,qa worked for me.
With Liquibase 3.2, support was added to for context expressions in changeSets.
An example: context=”qa or (dev and release)”
Newer versions have label which can be used for complex business cases.
Have you tried specifying the context at runtime as follows?
--contexts="new-db and edb"
If you want a change set to be executed in two contexts, namely dev and test, you probably want to use or instead of and:
or requires only one of the contexts.
and requires all contexts.
For example, the following change set will be applied in dev context, and it will also be applied in the test context:
-- changeset istepniak:db-1.14.1 context:dev or test
Instead, the following change set needs both contexts to be present:
-- changeset istepniak:db-1.14.1 context:dev and oracle
Related
I use liquibase diff generate the diff between dev mysql and prod mysql, I see there exist some change set like:
When I run the diff file, it shows exception like:
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-984::davy (generated)
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-985::davy (generated)
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-986::davy (generated)
at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:276)
at liquibase.Liquibase.update(Liquibase.java:198)
at liquibase.Liquibase.update(Liquibase.java:179)
at liquibase.integration.spring.SpringLiquibase.performUpdate(SpringLiquibase.java:317)
at liquibase.integration.spring.SpringLiquibase.afterPropertiesSet(SpringLiquibase.java:269)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
How to resolve this problem?
Object's comment update (Liquibase's set*Remarks) is not supported for some databases, including MySQL. So immediate fix could be to remove this action from your change log.
In my project we generating change sets by comparing (with liquibase diffChangeLog) 2 schemas, and setColumnRemarks actions are included although they cannot be executed afterwards. So I'm just removing these actions from resulting change sets.
I am afraid a proper solution would be to add appropriate MySQL SQL generator implementation to Liquibase.
I have a sequence in my database, which I generated through Liquibase. During refactoring, we decided that we didn't like the name that we gave it, and we would like to rename it, preserving all data that currently exists for it.
It seems possible to alter a sequence, but I'm not seeing anything about how to rename the sequence. Is there a way to do it, or a reasonable workaround?
(If it matters, I'm using Oracle SQL)
Although not documented, this refactoring is supported by Liquibase. Not sure what version this change was implemented in, but the class supporting the feature was commited on 30 Jan 2014. What's interesting though, is that the original issue is still unresolved.
Anyway, the refactoring is supposed to be working only on Oracle and Postgres. I've tested it on Oracle with Liquibase 3.4.1:
databaseChangeLog:
- changeSet:
id: change_set_id
author: me
dbms: oracle
changes:
- renameSequence:
oldSequenceName: old_name_seq
newSequenceName: new_name_seq
The above refactoring is in YAML format, but you could easily guess its XML counterpart.
On Oracle, this generates the following statement:
RENAME old_name_seq TO new_name_seq;
2 other supported parameters are catalogName and schemaName.
There is not currently a built-in refactoring to rename a sequence. If your database engine supports it, you could execute whatever methods are supported using a <sql> or <sqlFile> change.
You said you were using Oracle SQL. The RENAME statement allows for renaming a sequence. So your Liquibase script would look like this:
<sql>RENAME old_sequence_name TO new_sequence_name</sql>
I am attempting to generate a change log against a MariaDB server. I am able to successfully generate a change log, however if I do a dropAll and update to validate that it is useful, there are multiple problems with it. I have tried using both the native mariadb and MySQL jdbc connectors and both experience these problems. I am also using liquibase 3.1.1.
The first is that there are deferrable and initiallyDeferred flags which are not supported by MySQL. The update command specifically calls these out as being invalid flags against MySQL.
Once I remove all of those references in the .xml, attempting to update runs into a sql syntax error because a double datatype is defined as DOUBLE(22) (in the xml). This is not a valid syntax for a double in mariadb or MySQL. They accept no parameters, or DOUBLE(m,d); my database is defined as default (no parameters).
Now its trying to create a table with an auto_increment but not specifying that the column is also a key in the create table statement; ie. it's missing the primaryKey constraint.
And I'm sure there are more problems in line as I work my way through the changelog (this is just changeset 116 out of 1500+).
Its almost as if liquibase is creating the changelog based on it thinking the db is a different type (postgres/oracle?).
Am I missing something?
You are right, the problem is that Liquibase is thinking it is an unknown database and doesn't know it is almost mysql. There is an issue open to add mariaDB support (https://liquibase.jira.com/browse/CORE-1411) but it hasn't been implemented quite yet.
The easiest work-around would be to add an extension:
Create a new liquibase.database.ext.MariaDBDatabase class in your codebase that extends liquibase.database.core.MySQLDatabase and override the isCorrectDatabaseImplementation(DatabaseConnection conn) method that returns true if conn.getDatabaseProductName() equals whatever the MariaDB jdbc driver is returning.
You may also want to override the getDefaultDatabaseProductName() to return "mariadb" instead of MySQL so you can differentiate it with contexts
I use liquibase to generate SQL files based on the changeset . But when I am using liquibase:updateSQL , it is not checking for preconditions before generating the SQL file
I have a preconditions saying to check if the table exists , before creating the table .
In this scenario even though the tables are present the 'create table SQL statement is still getting generated.'
Where as when i run liquibase:update goal this precondition is checked properly .
So does not liquibase check for precondition while generating the sql file?
Thanks.
You probably have found an answer already, but just in case this might help:
http://forum.liquibase.org/topic/unexpected-behaviour-of-preconditions-with-updatesql
onSqlOutput="TEST" attribute for the precondition sounds like what you are looking for.
Just be careful with the the preconditions you write or when to test them while generating the updateSQL. Preconditions that rely on previously applied patches that might have not been executed yet in your instance could cause errors.
Hope it helps
Might help to provide some code. Especially your precondition to allow other to evaluate if it is an issue.
This question shows how to get Play! to show SQL statments. I followed on the accepted solution (jpa.debugSQL=true), but I still don't see the SQL statements that are used to create the tables themselves in the log.
How can I get those statements? (I'm currently using the in-memory database that comes with Play!, all default settings)
Note - if one of the SQL Schema statements goes wrong, it is displayed as an error in the log.
Check in application.conf the value of your property:
application.log=INFO
It may be hiding the output.
If you are using a log4j.properties file you may want, as Zenklys says, check the appenders set up in there.
You should use a log4j.properties file. If you define a logger on debug level on hibernate package you should be able to get the SQL statements.