Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

primary key on DATABASECHANGELOG, PK_DATABASECHANGELOG, is no longer created

Description

steps to reproduce

  • create empty database

  • populate the database using Liquibase

expected

  • DATABASECHANGELOG table should have PK_DATABASECHANGELOG on (ID, AUTHOR, FILENAME), as it was in older versions of Liquibase

observed

  • when database is populated using Liquibase 2.0,3, the DATABASECHANGELOG has PK_DATABASECHANGELOG primary key

  • if

    • the application now upgrades Liquibase to 3.0.8 and add some changes

    • database is updated

  • then DATABASECHANGELOG still has PK_DATABASECHANGELOG primary key

  • however, when database is populated from scratch (think: continuous integration env or new istallation), the DATABASECHANGELOG does not have PK_DATABASECHANGELOG primary key

Environment

oracle

Activity

Show:

Oleg Shtch October 26, 2018 at 8:14 AM

Sql Server require primary key for replication as well. Also Postgresql require primary key for logical replication.

Could you mention in documentation that liquidbase isn't acceptable in database clusters?

Thomas Lutz December 5, 2017 at 12:43 PM

In cluster setups like Galera, each table should have a primary key:

All tables should have a primary key (multi-column primary keys are supported). DELETE operations are unsupported on tables without a primary key. Also, rows in tables without a primary key may appear in a different order on different nodes.

https://mariadb.com/kb/en/library/mariadb-galera-cluster-known-limitations/

Nathan Voxland March 10, 2016 at 8:22 PM

We don't need a primary key by default because liquibase just does a "select * from databasechangelog" to get everything back, so an index isn't really going to help.

But, in case there are people who add one themselves I'm not going to automatically drop any primary keys on that table.

Mark Chesney May 8, 2015 at 6:24 PM
Edited

Below is an example of the simple workaround. I've optimized the indexes to reduce table scans, sorting and bookmark lookups on SQL Server, but it's probably equally applicable to Oracle. I was not really concerned about the maximum key length of 900 bytes on SQL Server being exceeded.

dbchangelog-CORE-1909.xml

Mark Chesney May 7, 2015 at 1:05 AM
Edited

A simple workaround could be to add a change set with a not primaryKeyExists pre-condition and addPrimaryKey change. A more involved workaround could be to create a plugin which overrides the CreateDatabaseChangeLogTableGenerator and/or StandardChangeLogHistoryService which implement PrioritizedService.

By Design

Details

Reporter

Affects versions

Priority

Created May 22, 2014 at 8:42 AM
Updated October 26, 2018 at 8:14 AM
Resolved March 10, 2016 at 8:22 PM