I have run into an issue with liquibase. So , I made a mistake in my sql commands in one of the changesets. Now whenever I try to upgrade my deployment , the upgrade is failing due to wrong checksum.
So I thought of doing the validCheckSum : ANY workaround and have run into this issue where it is not working. So my question is , is there any mistake in my syntax and How do I bypass the checksum check or what is the proper syntax for setting any in liquibase formatted sql.
This is what I have tried
--changeset darth: build-1.3
--validCheckSum: build-1.3:ANY
and it doesnt work.
Please help! Thanks!
The docs say:
Special value "1:any" will match to any checksum
Not sure why did you put "build-1.3:ANY"?
Also what you can do is:
Execute your code with latest liquibase changes onto an empty database
In DATABASECHANGELOG table look for the rows with changeset ids that you have been changing
Copy the MD5SUM value and paste it into your changeSet definition as a value of validCheckSum
It should run on any database with already executed changesets without errors.
It is worth mentioning that altering a change set is not recommended: by setting a validCheckSum value you will have "old" changeset already executed and "new" changes to this change set will be skiped. On an empty database your "new" changeset will be executed, so you will potentially have model inconsistencies.
Related
I'm trying to upgrade Liquibase from 3.3.1 to 3.10.3. Existing changesets are failing because varchar values being udpated are now inserting additional single quotes. Given the following statement in a changeset:
<update tableName="foo_table">
<column name="foo_id" type="VARCHAR(32)" value="'a'"/>
<where>bar_id REGEXP 'A'</where>
</update>
Liquibase seems to be adding additional single quotes in 3.10.3 so that values in the database are now stored with single quotes. Removing the single quotes from value in the changeset corrects the issue but will change the checksum on many of our changesets. I was wondering if there were any options available that will avoid us from needing to do that.
One option would be to create a new changelog (you can keep your old one, refer to both in order using includeAll in a master changelog). In the new changelog, you can just create your changes in sql.
This would allow you to write the change as sql exactly the way you want it, and liquibase would not have to render the sql based on xml.
I am using PDI to delete and insert some data from a DB. I have the following issue. I create two variables called START_DATE and END_DATE that are used to select the data that will be deleted from my DB. I am able to get them and run my transformation with no erors in the log file, but when I checked if data was deleted, I find it didn't. I send checked my "DeleteProcedure" step, and it says "Conversion error: null". I have tried different approached to take the variables and pass them as Strings, but I haven't been able to solve this issue. It cannot be a SQL mistake as I tested it with a constant and it works.
Any ideas? I attach some pics. Thanks!
As a documentation of the Execute SQL script says:
Note: When you have an issue, that the SQL is started at the initialization phase of the transformation and not for each row, make sure to check the option "Execute for each row" (see description below).
In your case it executes during the initialization phase of the transformation that's why it gets null values instead of ones from previous step.
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.
I have been researching a way to get the SQL statements that are built by a generated Migration file. These extend Doctrine_Migration_Base. Essentially I would like to save the SQL as change scripts.
The execution path leads me to Doctrine_Export which has methods that build the SQL statement and executes them. I have found no way of asking for just them. The export methods found in Doctrine_Export only operate on Doctrine_Record models and not Migration scripts.
From the command line './doctrine migrate version#' the path goes:
Doctrine_Cli::run(cmd)
Doctrine_Task_Migrate::setArguments(args)
Doctrine_Task_Migrate::execute()
Doctrine_Migration::migrate(to)
Doctrine_Migration_Process::Doctrine_Export::various
create, drop, alter methods with sql
equivalents.
Has anyone tackled this before? I really would not like to change Doctrine base files. Any help is greatly appreciated.
Could you make a dev server, and do the migration on that, storing a SQL Trace as you go?you don't have to keep the results, but you would get a list of every command.
Taking into account Rob Farley's suggestion, I modified:
Doctrine_Core::migrate
Doctrine_Task_Migrate::execute
When the execute method is called the optional argument 'dryRun' is checked. If true
then a 'Doctrine_Connection_Profiler' instance is created. The 'dryRun' value is then passed onto
the 'Doctrine_Core::migrate' method. The 'dryRun' value of true allows the changes to rollback when done executing the SQL statements. When the method returns, the profiler is parsed and non-empty SQL statements
not containing 'migration_version' are saved and displayed to the terminal.