I want to update very old changeset because there is a bug in that. I have updated that changesetid and After running it I got checksum error i.e checksum got modified. Now I have added validCheckSum Tag with this new checkSum. After it is getting successfully I cant not see new changes. Is there any way to update that change set which has already been executed.
Each changeSet tag is uniquely identified by the combination of the “id” tag, the “author” tag so please check whether id and author name already exists or not in DATABASECHANGELOG table. If the combination exists then change the id in your xml file then run the build
If still not works then add runOnChange property in <ChangeSet> and try it
runOnChange - Executes if any changes found it already existing changeset
Example of using runOnChange in changeset with sqlFile tag .
I had a script for Oracle 18 using IDENTITY column type and than have to change it for Oracle 10 which doesn't support IDENTITY column type
<changeSet id="2" author="auto" runOnChange="true">
<sqlFile dbms="oracle" encoding="utf8" endDelimiter=";" path="oracle/230.sql" relativeToChangelogFile="true" splitStatements="true" stripComments="true" />
</changeSet>
If it is a very old changeset as you have stated you should consider not changing the old changeset but add a new changeset instead which fixes the bug since it allows you better control over the versions you have. This is one of the main reasons of using liquibase.
Related
I'm very new at Liquibase, and I need some help.
I have an existing trigger that was not capturing all the data; I made some changes to my local Oracle database. Now I need to add those changes into the Liquibase, but I'm lost how to do that.
I know you cannot breach the contract in liquibase by updating the original .xml file directly.
From my understanding, I need to create a new changelog .XML file and then include the path on the other post_migration file.
My confusion is, do I have to drop the original trigger, then create a new file or?
Thanks!
I never create triggers, procedures or even views within the XML file exactly because this makes things more complicated (I think).
I typically move the actual trigger definition into a SQL script (that I can also run separately during development and testing), then include that SQL file from within the Liquibase changelog:
<changeSet id="42" author="arthur" runOnChange="true">
<sqlFile path="triggers/some_trigger.sql"
stripComments="false"
splitStatements="true"
endDelimiter="/"
relativeToChangelogFile="true"/>
</changeSet>
The some_trigger.sql script is stored in git (svn, ...) together with the XML changelog. The runOnChange="true" is the "magical ingredient" here. You don't have to touch the XML file, you just edit the SQL script. During deployment, Liquibase will check if the (SQL) file has changed and run the script if needec.
So, I believe that you create/update/replace the SQL trigger in your local developer database and right now you want to include the liquibase script to the release distribution package of your product.
The liquibase doesn't provide special xml syntax to create triggers, so you will just add a new changeset that holds your pl/sql script inside the <SQL> tag. The script will be the same that you run on your local database.
The example code here:
<changeSet id="1" author="me">
<sql endDelimiter="/">
CREATE OR REPLACE TRIGGER trigger_name before insert
on table1_name for each row
BEGIN
select seq_myseq.nextval
into :new.myid
from dual;
END;
/
</sql>
</changeSet>
This code just compile trigger in the aimed database when you call liquibase update. In most cases, it is enough. But I strictly recommend you to ask your DBA or team led for rules that your team enforced for writing liquibase scripts. For this reason, the result may be much more complicated.
in liquibase, there are 3 columns in the databasechangelog table, which uniquely identify a changeset and indicate if the changeset has been executed.
The columns are:
ID
AUTHOR
FILENAME (the changelogs file path)
As Liquibase executes the databaseChangeLog, it reads the changeSets in order and, for each one, checks the “databasechangelog” table to see if the combination of id/author/filename has been run.
I am using liquibase in the context of automated deployment, so the filepaths of my changesets change constantly. The same changeset therefore executes over and over again, which is unwanted behaviour.
Is there a way to exclude the filename from the combination that is the unique identifier of a changeset? I basically want liquibase to use ID and Author only.
Thank you
Kind regards,
Tobias
I think all you need to do is edit the changelog so that it has the logicalFilePath attribute set. Here's an example:
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.4.xsd"
logicalFilePath="changelog.xml">
...
</databaseChangeLog>
It is also possible to set the logicalFilePath attribute on individual changesets if necessary.
Some good forum posts on this as well: http://forum.liquibase.org/topic/i-need-to-ignore-the-filename-in-the-processing-to-see-if-a-change-set-has-already-been-applied
I’m using Liquibase via the Gradle-Liquibase (v 1.1.1) plugin. I have the following changeset …
<changeSet id="create_my_stored_proc" author="davea" dbms="mysql" runAlways="true">
<sqlFile endDelimiter="//" path="src/main/resources/scripts/create_my_stored_proc.sql" stripComments="true"/>
</changeSet>
Is it possible to set something such that checksums are ignored for this changeset only? The underlying procedure is in a state of flux that could be repeatedly updated and rather than create a new changeset each time, I would like the existing one to run upon every Liquibase build.
You can disable the checks per changeSet using the <validCheckSum> tag with known good values.
For example, if the previous changeset had a checksum like 8:b3d6a29ce3a75940858cd093501151d1 and you wanted to tweak that changeSet (but not re-apply it where this step has already succeeded) then you could use something like this:
<changeSet author="me" id="mychangeset">
<validCheckSum>8:b3d6a29ce3a75940858cd093501151d1</validCheckSum>
<sqlFile ... />
</changeSet>
"RunAlways will still throw a checksum error by default, but you can always use runOnChange=true or any to change that."
Have a look at this ticket raised in liquibase: https://liquibase.jira.com/browse/CORE-2506
So, you could do:
<changeSet id="create_my_stored_proc" author="davea" dbms="mysql" runAlways="true">
<validCheckSum>any</validCheckSum>
<sqlFile endDelimiter="//" path="src/main/resources/scripts/create_my_stored_proc.sql" stripComments="true"/>
</changeSet>
You can add the runAlways and/or runOnChange attributes.
I'm trying to tag a Formatted SQL changeset so a matching ID and tag are written to the DATABASECHANGELOG table (for rollback purposes - see changeset fragment below). The Phing liquibase task is being used to apply the 'update' command for a single changelog.
Although the 'tagDatabase' attribute isn't listed for Formatted SQL changelogs (http://www.liquibase.org/documentation/sql_format.html), neither is logicalFilePath, and that seems to be working OK!
Can someone let me know definitively if tagDatabase is not supported for a Formatted SQL changeset?
Many thanks in advance,
IR8
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--changeset id:123 logicalFilePath:path-independent
ALTER TABLE test1
ADD COLUMN text_column
text NULL;
--rollback ALTER TABLE test1 DROP COLUMN text_column;
--changeset id:tag123 tagDatabase:123;
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Unexpected error running Liquibase: No SQL for changeset ../db/changelog/databaseChangeLog.sql::tag123::id
Execution of target "migrate" failed for the following reason: C:\data\htdocs\TestLiquibase\deploy\build.xml:49:1: Liquibase exited with code -1
I think it's not included.
The java class FormattedSqlChangeLogParser takes care of parsing the formatted sql file and has a couple of Patterns defined for this. There is a logicalFilePathPattern but nothing for tagDatabase.
So this is not implemented yet.
From the official document,
When you run the updateToTag command or the Maven update goal with the liquibase.toTag attribute, and there is a row in the DATABASECHANGELOG table corresponding to the tagDatabase changeset in the changelog, the updateToTag command or the update Maven goal deploys all changesets starting with the first changeset at the top of the changelog file and moving down to the changeset up to the tag specified by the tagDatabase Change Type.
We can do one thing that is, after you executing all the SQL format changesets, we can create a new database tag changeset and update with liquibase
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">
<changeSet author="sivaramr" id="7">
<tagDatabase tag="v_1.0.0"/>
</changeSet>
</databaseChangeLog>
If you are using any liquibase command tool or liquibase plugins, then you can perform tag command to add the tag to the last changelog as follow
Here It is illustrated with gradle plugin.
./gradlew tag -PliquibaseCommandValue=v1.0.0
Before executing the above tag command, you can check the tag is already exist or not by tagexists command
./gradlew tagExists -PliquibaseCommandValue=v1.0.0
I want to start with a specific example where a table is created with a column having a constraint indicating this column is a foreign key:
<changeSet id="1" author="A1">
<createTable tableName="TABLE_A">
<!-- Other columns -->
<column name="FK_TABLE_B" type="BIGINT">
<!-- the 'TABLE_B' will be renamed soon ! -->
<constraints references="TABLE_B(ID_PK)"
foreignKeyName="JUST_UNIQUE_I_GUESS" nullable="false" />
</column>
</createTable>
</changeSet>
Now a first question: Assume TABLE_B would be renamed to TABLE_NEW... how would i want to change the above constraint so it points to the renamed Tables column ID_PK?
I see a few possibilities:
modify the changeSet itself (no Problem with a H2 inMemory DB... but cmon... thats not the idear right?)
Drop the whole column in my own changeSet and add it again with the new constraint which could make sence since the column name will probably change to FK_TABLE_NEW anyways... but thats not a real possibilitie for a productive environment
somehow alter that constraint -> BUT HOW!? the documentation is no
help at all...
The next question then is why to have this way of constraints if there is a
<addForeignKeyConstraint ...>
as well?
So currently i dont feel Liquibase at all just because this was my very first try to change an existing changeSet and my biggest question is: Is this a issue of not understanding the best practise or acctually a problem of the "not so verbouse" documentation?
Thanks for any help!
What i tried
assumed above constraints definition somehow leads to the same as a when done with a
<addForeignKeyConstraint ...>
tag but with less attributes. So i thought i could just use the
<dropForeignKeyConstraint ...>
tag first delete the ForeignKeyConstraint and then add a new one. But it still tells me it wont find table TABLE_B when trying to execute the first changeSet in a H2 in-memory DB.
My Changeset looked like this:
<changeSet id="1" author="A2">
<dropForeignKeyConstraint baseTableName="TABLE_A"
constraintName="JUST_UNIQUE_I_GUESS" />
<addForeignKeyConstraint
constraintName="JUST_UNIQUE_I_GUESS"
referencedTableName="TABLE_NEW" baseColumnNames="FK_TABLE_B"
baseTableName="TABLE_A" referencedColumnNames="ID_PK" />
</changeSet>
Background Information
Since were currently just building a POC using a in-memory DB only (H2) its no big deal to just change the first changeSet until we have quite of a final scheme-state... but how to deal with such things if you already have a existing DB, millions of entrys and stuff? Currently i highly doubt Liquibase is the right decision for a company with 1k+ developpers without hiring Liquibase Experts...
You should only modify your changesets as long as they (resp. the software/database that go along with the changesets) have not been released.
We keep our changeset files (along with the code) in our source code repository. During development phase everyone is allowed to change changesets defined for the version currently under development.
As soon as the version is released the changeset files are considered to be fixed and should not be changed anymore. (With the release the software is shipped and customers then have a database that reflects whatever the changesets define).
So after release you will have to create new changeSets that
drop the foreign key constraint
rename your table
add a new foreign key constraint
More or less, you need to do exactly what you would do with pure sql on the database as well.
At this point liquibase will more or less just translate your changeSets to sql and apply them to the database. So once you found a way to do your changes with slq it should also be possible to put those into liquibase changesets.