-
- 127.0.0.1 localhost
- ::1 localhost
Re : Could not initialize class liquibase.sqlgenerator.core.LockDatabaseChangeLogGenerator
Re : Could not initialize class liquibase.sqlgenerator.core.LockDatabaseChangeLogGenerator
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
Re : generateChangeLog don't identify different schemas, just "dbo" (MSSQL 2008)
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
property tag does not seem to be respecting the context attribute
< property name ="propName" value ="DEV" context ="dev"/>
< property name ="propName" value ="ANY_OTHER" context =""/>
Auto-Increment Precondition
- <changeSet id="1" author="emi">
- <addAutoIncrement columnDataType="int"
- columnName="id"
- incrementBy="1"
- startWith="1"
- tableName="log"/>
- </changeSet>
However, this fails when I run it on my databases that already have this auto-increment.
I'd like something like this:
- <changeSet id="1" author="emi">
- <preConditions>
- <not>
- <autoIncrementExists columnName="id"
- tableName="log"/>
- </not>
- </preConditions>
- <addAutoIncrement columnDataType="int"
- columnName="id"
- incrementBy="1"
- startWith="1"
- tableName="log"/>
- </changeSet>
Is this possible in any way?
PS: If you're wondering why I ended up with this inconsistency on my databases, it's because MySQL deletes the auto-increment when you change a column type, while PostgreSQL doesn't.
Re : cannot sign up on liquibase.jira.com
Re : cannot sign up on liquibase.jira.com
Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists
Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists
Thanks for your response.
I have 2 xml files. At first level it has only an include file.
At the second level it contains the real action to do.
See the attached files. hope it helps you.
I'm not using new Vertica types. I'm just starting to use it with basic stuff.
Regards
Mohamed
Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists
- <changeSet id="5" author="test">
- <ext:createTable partitionby="floor((timestamplong / 86400000))" tableName="TEST_VERTICA_2">
- <column name="id" type="INT">
- <constraints nullable="false"/>
- </column>
- <column name="timestamp" type="timestamp">
- <constraints nullable="false"/>
- </column>
- <column name="timestamplong" type="INT" encoding="RLE">
- <constraints nullable="false"/>
- </column>
- </ext:createTable>
- </changeSet>
Strange things with Java 8
Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists
Thank you, your upgrade works perfectly.
Thanks also for your advice regarding using xml instead sql. Currently we have chosen to use liquibase with sql file because it is a simpler method to move all projects (we have too many of them) into this new tool and also people here are not keen to manipulate xml files, especially production DBA.
Regards,
Mohamed
Checksum error after upgrading from 3.20 to 3.2.2
We upgraded liquibase-core from 3.2.0 to 3.2.2 and get the following error:
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
18 change sets check sum
….
de/test/evolution/changelog/r_1_0_15/changelog-150-663.xml::150-663::kwettemann is now: 7:0b42e8dfdeca6e429736122cc3698ab2
at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:181)
at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:771)
at de.persis.nova.evolution.LiquibaseEvolutionProvider.isEvolutionNeeded(LiquibaseEvolutionProvider.java:54)
... 59 more
The entry from the databasechangelog table:
"150-663";"kwettemann";"de/test/evolution/changelog/r_1_0_15/changelog-150-663.xml";"2014-09-09 11:02:58.367";65;"EXECUTED";"7:0ad1843271aa0469ddc62d26ab70b364";"insert";"''";"";"3.2.0"
I’m not sure but probably this has something to do with the changes at the checksum computation.
Is this a bug or is there something we have to do when upgrading from 3.2.0 to 3.2.2?
Thx and Regards,
Stefan
Re : Incorrect default charset for formatted sql files via maven plugin
set character set and collate for full unicode support
Documentation bug for dropTable
the documentation for dropTable states that the attribute "cascadeConstraints" is supported for all DBMS.
At least for SQL Server this is not true
Consider the following changeLog:
- <?xml version="1.0" encoding="utf-8"?>
- <databaseChangeLog xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns="http://www.liquibase.org/xml/ns/dbchangelog">
-
- <changeSet author="hasn" id="1">
- <createTable tableName="bar">
- <column name="id" type="int">
-
<constraints nullable="false"
-
primaryKey="true"
- primaryKeyName="pk_bar" />
- </column>
- </createTable>
-
- <createTable tableName="foo">
- <column name="id" type="int" />
- <column name="bar_id" type="int" />
- </createTable>
-
-
<addForeignKeyConstraint constraintName="fk_bar_foo"
-
baseTableName="foo" baseColumnNames="bar_id"
- referencedTableName="bar" referencedColumnNames="id" />
- </changeSet>
-
- <changeSet author="hans" id="2">
- <dropTable tableName="bar" cascadeConstraints="true"/>
- </changeSet>
-
- </databaseChangeLog>
Error executing SQL DROP TABLE [dbo].[bar]: Could not drop object 'dbo.bar' because it is referenced by a FOREIGN KEY constraint.
To my knowledge this only works on Postgres, Oracle, DB2, H2 and HSQLDB.
generatechangelog on oracle sets user to upper case
- liquibase --changeLogFile="origChangeLog.xml" --logLevel="debug" generateChangeLog
- #Liquibase.properties
- driver: oracle.jdbc.OracleDriver
- url: jdbc:oracle:thin:@localhost:1521:XE
- username: "dbuser"
- password: ***
- liquibase --changeLogFile="origChangeLog.xml" --logLevel="debug" generateChangeLog
- DEBUG 9/16/14 1:26 PM:liquibase: Connected to "dbuser"@jdbc:oracle:thin:@localhost:1521:XE
- DEBUG 9/16/14 1:26 PM:liquibase: Setting auto commit to false from true
- DEBUG 9/16/14 1:26 PM:liquibase: Executing QUERY database command: SELECT SEQUENCE_NAME FROM ALL_SEQUENCES WHERE SEQUENCE_OWNER = 'DBUSER'
- INFO 9/16/14 1:26 PM:liquibase: origChangeLog.xml exists, appending
- DEBUG 9/16/14 1:26 PM:liquibase: MissingObjectChangeGenerator type order: liquibase.structure.core.Catalog liquibase.structure.core.Schema liquibase.structure.core.Sequence liquibase.structure.core.StoredProcedure liquibase.structure.core.Table liquibase.structure.core.Column liquibase.structure.core.PrimaryKey liquibase.structure.core.ForeignKey liquibase.structure.core.UniqueConstraint liquibase.structure.core.Index liquibase.structure.core.View
- DEBUG 9/16/14 1:26 PM:liquibase: UnexpectedObjectChangeGenerator type order: liquibase.structure.core.Catalog liquibase.structure.core.ForeignKey liquibase.structure.core.Schema liquibase.structure.core.StoredProcedure liquibase.structure.core.UniqueConstraint liquibase.structure.core.View liquibase.structure.core.Table liquibase.structure.core.PrimaryKey liquibase.structure.core.Column liquibase.structure.core.Index liquibase.structure.core.Sequence
- DEBUG 9/16/14 1:26 PM:liquibase: ChangedObjectChangeGenerator type order: liquibase.structure.core.Catalog liquibase.structure.core.ForeignKey liquibase.structure.core.Schema liquibase.structure.core.Sequence liquibase.structure.core.StoredProcedure liquibase.structure.core.Table liquibase.structure.core.Column liquibase.structure.core.PrimaryKey liquibase.structure.core.Index liquibase.structure.core.UniqueConstraint liquibase.structure.core.View
- INFO 9/16/14 1:26 PM:liquibase: No changes found, nothing to do
- Liquibase 'generateChangeLog' Successful
Using Liquibase on Teradata 14.
Allow multi-schema database installations without need for elevated (DBA) rights
- You have done a huge amount of good work with Liquibase.
- So far, I miss only one feature.
-
-
- Background (terms and examples are Oracle centric):
- Most of "logical databases" (that I have been dealing with) do not consist of 1 schema only.
- There are many schemas and usually there are cross dependencies between schemas.
- More precisely, there are 2 types of schemas:
- Schemas (include tables, views, procedures etc) with cross-dependencies
- Users for application servers and for batch processes (include received object grants and optionally synonyms)
-
-
- Expectation for database installation procedure:
- first, DBA will create everything that is not application specific: schemas, users, tablespaces, system grants etc
- Liquibase installs "changelog.xml" (which contains all schemas of "logical database") with one run.
- for each next release Liquibase installs "changelog.xml" (which contains all schemas of "logical database") with one run.
-
-
- Current situation / Issues with alternatives:
- Recommendation: use DBA rights for installation.
Unfortunately, there exist SQL commands that can only be executed by schema owner. For example: CREATE DATABASE LINK ... You may have DBA rights but you still can not create database link into another schema.
There is (smaller) issue with grants as well. If DBA executes "grant select on schema1.table to schema2" then grantor is registered as DBA. From application point of view DBA is nobody.
- Security issue. DBA right means that you can do everything in that
physical database
Today, many "logical databases" are consolidated into one "physical database".
It means, each "logical database" developer/deployer/installer have DBA rights in physical database.
They can see and change everything in all "logical databases"
This is totally NOT acceptable for Security Officers / IT Risks and for DBA.
-
-
- Need:
- For multi-schema "changelog.xml" installation, each schema needs its own connection to database to have/get proper permissions and proper context for SQL execution.
- "Proper permission" means here as well that permissions
are strictly limited to schema owner permissions. DBA rights must
not be available unless it is intentionally granted.
-
-
- Proposal:
- I would like to have optional possibility to specify schema name for each "changeSet".
-
- For example this way:
- <changeSet id="1" author="Marek" runAs="DB_USER_1"> ...
- <changeSet id="2" author="Marek" runAs="DB_USER_2"> ...
- <changeSet id="3" author="Marek" runAs="DB_USER_3"> ...
- <changeSet id="4" author="Marek" runAs="DB_USER_1"> ...
- <changeSet id="5" author="Marek" runAs="DB_USER_3"> ...
-
- In configuration there is need for one entry for each referred schema name to set password.
- "DB_USER_1" can also be alias and in configuration there will be matching database username and password.
-
- I still expect that there is single central DATABASECHANGELOG table for one "logical database" as it is already today.
-
-
- PS:
- We would like to use Liquibase for all database deployments on Oracle databases.
- Today, we can do it for single-schema deployments only. Unfortunately, this cover ~20% of cases.
- .
- I think this proposed (in my opinion small) improvement would remove last big barrier to start using Liquibase for the rest 80% of cases as well.
-
-
- Thank you in advance,
- Marek Läll
Re : Using Liquibase on Teradata 14.
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/