Error setting up or running liquibase

Thanks, now my set up almost works! I am still running in this NPE, though:

Caused by: java.lang.NullPointerException
    at liquibase.ext.hibernate.snapshot.PrimaryKeySnapshotGenerator.addTo(PrimaryKeySnapshotGenerator.java:59)
    at liquibase.ext.hibernate.snapshot.HibernateSnapshotGenerator.snapshot(HibernateSnapshotGenerator.java:80)
    at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
    at liquibase.ext.hibernate.snapshot.HibernateSnapshotGenerator.snapshot(HibernateSnapshotGenerator.java:72)
    at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
    at liquibase.ext.hibernate.snapshot.HibernateSnapshotGenerator.snapshot(HibernateSnapshotGenerator.java:72)
    at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
    at liquibase.ext.hibernate.snapshot.HibernateSnapshotGenerator.snapshot(HibernateSnapshotGenerator.java:72)
    at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
    at liquibase.snapshot.DatabaseSnapshot.include(DatabaseSnapshot.java:163)
    at liquibase.snapshot.DatabaseSnapshot.replaceObject(DatabaseSnapshot.java:241)
    at liquibase.snapshot.DatabaseSnapshot.replaceObject(DatabaseSnapshot.java:263)
    at liquibase.snapshot.DatabaseSnapshot.includeNestedObjects(DatabaseSnapshot.java:195)
    at liquibase.snapshot.DatabaseSnapshot.include(DatabaseSnapshot.java:177)
    at liquibase.snapshot.DatabaseSnapshot.init(DatabaseSnapshot.java:60)
    at liquibase.snapshot.DatabaseSnapshot.<init>(DatabaseSnapshot.java:37)
    at liquibase.snapshot.JdbcDatabaseSnapshot.<init>(JdbcDatabaseSnapshot.java:25)
    at liquibase.snapshot.SnapshotGeneratorFactory.createSnapshot(SnapshotGeneratorFactory.java:126)
    at liquibase.snapshot.SnapshotGeneratorFactory.createSnapshot(SnapshotGeneratorFactory.java:119)
    at liquibase.command.DiffCommand.createReferenceSnapshot(DiffCommand.java:190)
    at liquibase.command.DiffCommand.createDiffResult(DiffCommand.java:140)
    at liquibase.command.DiffCommand.run(DiffCommand.java:132)
    at liquibase.command.AbstractCommand.execute(AbstractCommand.java:8)
    ... 32 more

But this is probably not related to this issue anymore. Should I open another issue? Or do you think this is because of some misconfiguration?

Here is my current setup:

            <plugin>
                <groupId>org.liquibase</groupId>
                <artifactId>liquibase-maven-plugin</artifactId>
                <version>3.4.0-SNAPSHOT</version>
                <configuration>
                    <propertyFile>src/main/resources/config/liquibase/liquibase.properties.generation</propertyFile>
                    <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>org.liquibase</groupId>
                        <artifactId>liquibase-core</artifactId>
                        <version>3.4.0-SNAPSHOT</version>
                        <exclusions>
                            <exclusion>
                                <artifactId>jetty-servlet</artifactId>
                                <groupId>org.eclipse.jetty</groupId>
                            </exclusion>
                        </exclusions>
                    </dependency>
                    <dependency>
                        <groupId>org.liquibase.ext</groupId>
                        <artifactId>liquibase-hibernate4</artifactId>
                        <version>3.5-SNAPSHOT</version>
                        <exclusions>
                            <exclusion>
                                <artifactId>hibernate-jpa-2.0-api</artifactId>
                                <groupId>org.hibernate.javax.persistence</groupId>
                            </exclusion>
                        </exclusions>
                    </dependency>
                    <dependency>
                        <groupId>org.liquibase.ext</groupId>
                        <artifactId>liquibase-hibernate4</artifactId>
                        <version>3.5-SNAPSHOT</version>
                    </dependency>
                    <dependency>
                        <groupId>org.springframework</groupId>
                        <artifactId>spring-context-support</artifactId>
                        <version>${spring.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>org.springframework</groupId>
                        <artifactId>spring-orm</artifactId>
                        <version>${spring.version}</version>
                    </dependency>
                    <dependency>
                        <groupId>xml-apis</groupId>
                        <artifactId>xml-apis</artifactId>
                        <version>1.4.01</version>
                    </dependency>
                </dependencies>
            </plugin>

changeLogFile: src/main/resources/config/liquibase/master.xml
#diffChangeLogFile: src/main/resources/config/liquibase/changelog/20150105150500_main_schema.xml
driver: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost:3306/project_template
defaultSchema: project_template
username: root
password: root
referenceUrl: hibernate:spring:app.model?dialect=org.hibernate.dialect.MySQL5Dialect
verbose: true
dropFirst: false
logging: debug

All About Changeset Checksums

Updated October 8, 2021

In order to detect changes between what is currently in the changelog vs. what was actually run against the database, Liquibase stores a checksum with each changeset entry in the DATABASECHANGELOG tracking table.

Liquibase uses a checksum to detect if your target database was updated. The checksum is computed after the parameters are applied. For example, let’s say your target database already ran the following changeset:

This changeset adds “my_column” as an “int”. The changelog contains the same “id=1, author=example” changeset as the following changeset:

This changeset adds “my_column” as a “bigint” instead.

Since Liquibase tracks which changesets have run against your target database by the id/author/filepath combination, it sees the updated changeset as “ran” even though your target database has “my_column” as an “int” column rather than the expected “bigint” type.

If you run the “int” changeset against your database and then change it to “bigint” and re-run update, Liquibase will exit with the following error:

This error shows how Liquibase notices that your target database is out of sync with the changelog.

However, not every change to a changeset impacts the checksum. Here are some examples:

• Reformatting whitespace and linebreaks (except within SQL statements)
• Changing preconditions
• Changing contexts
• Changing labels
• Adding validCheckSum settings
• Changing comments (via native xml/yaml comments or using the comment tag)

Troubleshooting checksums

Don’t fear the checksum. It is here to help you add metadata to changesets that have already been run without problems. Checksums are also helpful because they can catch errors early in your pipeline and revert the changeset back to the original version and help you roll forward with a new changeset.

If you do end up with a checksum issue, you have several options to address it.

Revert and roll forward

Using our earlier example above, you can set the type back to “int” and add a new modifyDataType changeset to change the column from “int” to “bigint”. Previous development databases would need to be rebuilt with the correct checksum, but the fact that they didn’t catch the checksum error originally means they are ephemeral and rebuilding is the easier option.

Valid checksum tag

If the revert + roll-forward approach doesn’t work for you, you can use the tag to specify which checksum that you want to accept as valid, even if it’s different than what was stored in the DATABASECHANGELOG table. Use the checksum values from the error message.

Using our example, your final changeset would look like the following:

The type is still “bigint”, but it now has a validCheckSum tag.

Running this changeset against your database which originally ran the “int” version will no longer complain about the checksum error — but it still considers the changeset as “ran”. That means the column will remain an “int”.

If that is okay with you, you can leave it that way. If it’s not okay and you want to update it, you can add an additional modifyDataType changeset from “int” to “bigint” with a “changeSetRan” onFail=MARK_RAN precondition right before the addColumn changest. Doing this will migrate only databases that had already run the changest and leave the rest.

Manually modify

Of course, if it is just a handful of “problem” databases, you can also just manually modify their datatype and be done.

Источник

Liquibase error: 1 change sets check sum #478

Comments

yarmail commented Apr 22, 2021 •

Возможно кому-то покажется полезным, особенно ученикам,
которые вынуждены часто исправлять свои таблицы.
Возможно это следует добавить к работе с Liquibase

Ситуация такая:
В проекте Grabber нужно было обновить таблицу Post.
Я убрал её командой
drop table if exists post cascade;

После этого в скрипте хотел создать таблицу заново (с тем же именем),
но получил ошибку в Maven test такого плана:

. Failed to execute goal org.liquibase:liquibase-maven-plugin
. 1 change sets check sum .

Если я правильно понимаю — есть проблема создавать таблицы с одинаковыми
названиями. Liquibase каждой таблице присваивает уникальный номер (check sum)
и поэтому ругается, когда имена таблиц совпадают, а номера нет.

Возможное решение: перед созданием новой таблицы с похожим именем
выполнить команду в терминале:
mvn liquibase:clearCheckSums
Источник:
https://docs.liquibase.com/tools-integrations/maven/commands/maven-clearchecksums.html

Также возможно для целей обучения, (если кураторы сочтут это необходимым)
имеет смысл поменять настройки Liquibase в pom.
Если я правильно понимаю, это что-то типа такого:
.
groupId org.liquibase groupId
.
goal clearCheckSums goal

The text was updated successfully, but these errors were encountered:

Источник

AppDynamics Community

Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.

AppDynamics customers and established members should click the sign in button to authenticate.

• AppDynamics Community
• Knowledge Base
• How do I fix a Liquibase validation error during a.

• Subscribe to RSS Feed
• Mark as New
• Mark as Read
• Bookmark
• Subscribe
• Printer Friendly Page
• Report Inappropriate Content

How do I fix a Liquibase validation error during a EUM Schema update?

• Article History
• Subscribe to RSS Feed
• Mark as New
• Mark as Read
• Bookmark
• Subscribe
• Printer Friendly Page
• Report Inappropriate Content

on ‎04-27-2020 12:14 PM — edited on ‎06-05-2020 01:13 PM by Claudia.Landiva r

Resolving an intermittent Liquibase error when upgrading to EUM Server v4.5 from a version lower than 4.4

Problem

As of the 4.5 EUM Server in production, the EUM MySQL database has been moved from the Controller host machine to the EUM Server host machine.

As a result, when upgrading to EUM Server version 4.5 from a version lower than 4.4, t you may see this intermittent error after the database has been imported and during the schema update:

Solution

To resolve this error, log in to the EUM database and run this SQL query:

Then, run the eum-schema command again, using the root user:

For alternate solution, execute these commands:

Источник

Changelog Formats

The changeset tag is a unit of change that Liquibase executes on a database and which is used to group database Liquibase Change Types together. A list of changes created by multiple changeset s are tracked in a changelog .

A changeset is uniquely tagged by both an author and an id attribute s ( author:id ), as well as the changelog file path. The id tag is only used as an identifier, it does not direct the order that changes are run and does not have to be an integer. If you do not know or do not want to save the actual author, use a placeholder value such as UNKNOWN . To execute the changeset , you must include both author and id .

Running the changeset

As Liquibase uses the DATABASECHANGELOG table, it reads the changeset s in order and, for each one, checks the DATABASECHANGELOG table to see if the combination of id/author/filepath has been run.

If it has been run, the changeset will be skipped unless there is a runAlways tag set to true in that changeset . After all the changes in the changeset s are run, Liquibase will insert a new row with the id/author/filepath along with an MD5Sum of the changeset in the DATABASECHANGELOG .

Note: filepath is the path that defines the changelog-file attribute . Even if the same file is referenced with a different path, that is considered a different file unless the logicalFilePath is defined.

Liquibase attempts to execute each changeset in a transaction that is committed at the end, or rolled back if there is an error. Some databases will auto-commit statements which interferes with this transaction setup and could lead to an unexpected database state. Therefore, it is best practice to have just one change per changeset unless there is a group of non-auto-committing changes that you want to apply as a transaction such as inserting data.

Available attribute s

Specifies an alpha-numeric identifier. Required

Note: If there are zeros in the id, it is best practice to put quotes around the id. ie: «1.10» This allows all characters to be retained.

author Specifies the creator of the changeset . Required dbms Specifies the type of a database for which that changeset will be used. When the migration step is running, it checks the database type against this attribute .

Note: For more information about database type names, see Supported databases page.

Also, you can do the following:

• List multiple databases separated by commas.
• Specify that a changeset is not applicable to a particular database type by prefixing it with ! .
• Add the keywords all and none .

runAlways Executes the changeset on every run, even if it has been run before. runOnChange Executes the changeset the first time and each time the changeset has been changed. Contexts Controls whether a changeset is executed depending on runtime settings. Any string can be used for the context name and they are checked case-insensitively. Labels Controls whether a changeset is executed depending on runtime settings. Any string can be used for the label name and they are checked case-insensitively. runInTransaction

Specifies whether the changeset can be ran as a single transaction (if possible). Default value is true .

Warning: If this attribute is set to false and an error occurs part way through running a changeset that contains multiple statements, the Liquibase DATABASECHANGELOG table will be left in an invalid state. Since 1.9

failOnError Defines whether the migration will fail if an error occurs while executing the changeset . Default value is true . objectQuotingStrategy Controls how object names are quoted in the SQL files generated by Liquibase and used in calls to the database. Default value is LEGACY .

• LEGACY – The default value. Does not quote objects unless the database specifies that they must be quoted, usually including reserved words and names with hyphens. In PostgreSQL databases, mixed-case names will also be quoted.
• QUOTE_ALL_OBJECTS – Every object gets quoted. For example, person becomes «person».
• QUOTE_ONLY_RESERVED_WORDS – The same logic as LEGACY , but without mixed-case objects in PostgreSQL databases.

runOrder Overrides the order in the changelog from where the changeset with the runOrder=»first|last» will be run. It is typically used when you want a changeset to be always executed after everything else but don’t want to keep moving it to the end of the changelog . Setting the runOrder to last will automatically move it in the final changeset order.Since 3.5

Note: The runOrder changeset attribute is not supported in formatted SQL changeset s.

created Stores dates, versions, or any other string of value without using remarks (comments) attribute s. Since 3.5 ignore Ignores the changeset from the execution. Since 3.6 logicalFilePath Overrides the file name and path when creating the unique identifier of changeset s. Required when moving or renaming changelog .

Available sub-tags

Note: For more information, see Preconditions.

Specifies the database change(s) to run as part of the changeset (Liquibase Change Types). validCheckSum Adds a checksum that is considered valid for this changeset , regardless of what is stored in the database. It is primarily used when you need to change a changeset and don’t want errors thrown on databases on which it has already been run (not a recommended procedure). Special value «1:any» will match to any checksum and will not execute the changeset on ANY change. Since 1.7 rollback Specifies SQL statements or Change Type tags that describe how to rollback the changeset .

The rollback tag

The rollback tag describes how to roll back a change using SQL statements, Change Type s, or a reference to a previous changeset .

Note: For more information about the rollback tag and examples, see Auto Rollback.

changeset checksums

When Liquibase reaches a changeset , it computes a checksum and stores it in the DATABASECHANGELOG table. The value of storing the checksum for Liquibase is to know if something has been changed in the changeset since it was run.

If the changeset has been changed since it was run, Liquibase will exit the migration with an error message like Validation failed: change set check sums was:

but is now: . This is because Liquibase cannot identify what was changed and the database may be in a state different than what the changelog is expecting. If there was a valid reason for the changeset to be changed and you want to ignore this error, there are two options.

Note: You can also use the clear-checksums command to resolve the checksum error, however, it will clear the entire column of checksums in your DATABASECHANGELOG table.

The manual update of the DATABASECHANGELOG table

The first option is to manually update the DATABASECHANGELOG table so that the row with the corresponding id/author/filepath has a null value for the checksum. You would need to do this for all environments where the changeset has been deployed. The next time you run the Liquibase update command, it will update the checksum value to the new correct value.

The attribute

The second option is to add a element to the changeset . The text contents of the element should contain the old checksum from the error message.

The runOnChange attribute

Checksums are also used in conjunction with the runOnChange changeset attribute . There are times you may not want to add a new changeset because you only need to know about the current version, but you want this change to be applied whenever it is updated. For example, you can do this with stored procedures.

If you copy the entire text of the stored procedure to a new changeset each time you make a change, you will not only end up with a very long changelog , but you will lose the merging and diffing power of your source control. Instead, put the text of the stored procedure in a changeset with a runOnChange=»true» attribute . The stored procedure will be re-created when there is a change to the text of it.

Note: For more information, see runOnChange.

Источник