Quantcast
Viewing all 2993 articles
Browse latest View live

Re : Could not initialize class liquibase.sqlgenerator.core.LockDatabaseChangeLogGenerator

OK so I debugged my maven test and found that the static method in LockDatabaseChangeLogGenerator was throwing the error. I am getting this error:

java.net.UnknownHostException: DEAN:DEAN.

When I check my hosts file, I'm seeing this:

# localhost name resolution is handled within DNS itself.

  1. 127.0.0.1       localhost
  2. ::1             localhost

Not sure what is causing this at this point. Can someone assist?

Re : Could not initialize class liquibase.sqlgenerator.core.LockDatabaseChangeLogGenerator

Looks like some sort of networking issue. Somewhere in your config you are asking for a connection to DEAN:DEAN, but that is not resolving. If that is your own machine, you might try changing the name to localhost rather than DEAN. 

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

Re : generateChangeLog don't identify different schemas, just "dbo" (MSSQL 2008)

property tag does not seem to be respecting the context attribute

Has anyone else encountered the issue where the <property> tags in the change log files are not using the context attribute?

In a situation like the below, the value *always* gets set to "DEV" regardless of the contexts passed in.

< property name ="propName" value ="DEV" context ="dev"/>

< property name ="propName" value ="ANY_OTHER" context =""/>


I need for the property to have different values depending on the context being run.

Does anyone know any tricks to get this to work?  Or is this a bug that will need to get fixed in the core code?

Thanks.

Auto-Increment Precondition

Some of my databases have an auto-increment on the id column of my log table, while others don't. As I need this auto-increment on all of my databases, I created a changeSet like this:

  1.     <changeSet id="1" author="emi">
  2.         <addAutoIncrement columnDataType="int"
  3.                 columnName="id"
  4.                 incrementBy="1"
  5.                 startWith="1"
  6.                 tableName="log"/>
  7.     </changeSet>

However, this fails when I run it on my databases that already have this auto-increment.

I'd like something like this:

  1.     <changeSet id="1" author="emi">
  2.         <preConditions>
  3.                   <not>
  4.                         <autoIncrementExists columnName="id"
  5.                               tableName="log"/>
  6.                   </not>
  7.         </preConditions>
  8.         <addAutoIncrement columnDataType="int"
  9.                 columnName="id"
  10.                 incrementBy="1"
  11.                 startWith="1"
  12.                 tableName="log"/>
  13.     </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

Thanks, I've found the setting in the user admin section so you should be able to log in now.

Sorry for the inconvenience.

Nathan

Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists

Hi mohamed ,
sorry for the late response,
I wrote the Vertica extension for liquibase and i'm currently working to upgrade it for version 7.1 and liquibase 3.2.2 
(it was written for version 6.1.2 of vertica and earlier liquibase version)

If you can share your changeset i'd be happy to debug/extend since as i said i currently working to update it.

From the stack trace you attached it seems that i don't have support for a data type you defined - do you happen to use one of the new types define in vertica 7?

Regards,
 - Jony

Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists

Hi Jony,

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

Hi Mohamed,

I've created an initial update for the extension to work with vertica 7.1 on liquibase 3.2.2 (latest stable release)

also note it's better to use XMLs as changes since it can better rollback and manage your changes (it treats SQLs as scripts - it doesn't parse them to know what you want)

an example changeSet could be:
  1. <changeSet id="5" author="test">
  2.     <ext:createTable partitionby="floor((timestamplong / 86400000))" tableName="TEST_VERTICA_2">
  3.         <column name="id" type="INT">
  4.             <constraints nullable="false"/>
  5.         </column>
  6.         <column name="timestamp" type="timestamp">
  7.             <constraints nullable="false"/>
  8.         </column>
  9.         <column name="timestamplong" type="INT" encoding="RLE">
  10.             <constraints nullable="false"/>
  11.         </column>
  12.     </ext:createTable>
  13. </changeSet>
I hope it will prove useful to you :)
Regards,
 - Jony

Strange things with Java 8

Today I ran the "usual" things I did hundreds of times, and I had a strange "bug". I'm not sure whether it's a bug in liquibase or in Java 8, but this is what happened:

`liquibase update` against a RedShift DB displayed the same error we had in http://forum.liquibase.org/topic/redshift-support , because it doesn't add the escaping double-quotes around the reserved keyword of RedShift: TAG

Took us some time, but finally we found out that the fix was to run liquibase with Java 7 instead of 8.


Re : Liquibase 3.3 with Vertica DB : "DATABASECHANGELOG" already exists

Hi Jony,

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

Nathan, it would be awsome if this could be done through liquibase. Thank you so much.

set character set and collate for full unicode support

MySQL doesn't support full UTF-8 encoding by default. This article explains how to change character set and collate in tables so this can be accomplished.

It would be very nice if it could be done using liquibase!

Documentation bug for dropTable

Hello,

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:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <databaseChangeLog xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
  3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4.     xmlns="http://www.liquibase.org/xml/ns/dbchangelog">

  5. <changeSet author="hasn" id="1">
  6.    <createTable tableName="bar">
  7.      <column name="id" type="int">
  8.         <constraints nullable="false"
  9.            primaryKey="true"
  10.            primaryKeyName="pk_bar" />
  11.      </column>
  12.    </createTable>

  13.    <createTable tableName="foo">
  14.       <column name="id" type="int" />
  15.       <column name="bar_id" type="int" />
  16.    </createTable>

  17.    <addForeignKeyConstraint constraintName="fk_bar_foo"
  18.       baseTableName="foo" baseColumnNames="bar_id"
  19.       referencedTableName="bar" referencedColumnNames="id" />
  20.    </changeSet>

  21.   <changeSet author="hans" id="2">
  22.     <dropTable tableName="bar" cascadeConstraints="true"/>
  23.   </changeSet>

  24. </databaseChangeLog>
The changeSet id="2" will fail with the error message:

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

I am attempting to generate a change log from my existing database using the generatechangelog command, However the resulting changelog is blank. running the command with the debug logging turned on I can see that the command is running the sql statement SELECT SEQUENCE_NAME FROM ALL_SEQUENCES WHERE SEQUENCE_OWNER = 'DBUSER'. The issue is that the user that I have in my database is "dbuser". How can I set liquibase to not capitalize the username field when running the generateChangeLog command. This also appears to be an issue with the diff commands as well. when I run the sql command directly in oracle, due to the case mismatch it returns no results.

I am running liquibase 3.1.1 to support the spatial plugin, but I tested it on 3.2.2 and the issue is still present there.

The command and properties that I am running:
  1. liquibase --changeLogFile="origChangeLog.xml" --logLevel="debug" generateChangeLog

  1. #Liquibase.properties
  2. driver: oracle.jdbc.OracleDriver
  3. url: jdbc:oracle:thin:@localhost:1521:XE
  4. username: "dbuser"
  5. password: ***

I have tried both this and username: dbuser both produce the same results.

the debug log results:
  1. liquibase --changeLogFile="origChangeLog.xml" --logLevel="debug" generateChangeLog
  2. DEBUG 9/16/14 1:26 PM:liquibase: Connected to "dbuser"@jdbc:oracle:thin:@localhost:1521:XE
  3. DEBUG 9/16/14 1:26 PM:liquibase: Setting auto commit to false from true
  4. DEBUG 9/16/14 1:26 PM:liquibase: Executing QUERY database command: SELECT SEQUENCE_NAME FROM ALL_SEQUENCES WHERE SEQUENCE_OWNER = 'DBUSER'
  5. INFO 9/16/14 1:26 PM:liquibase:  origChangeLog.xml  exists, appending
  6. 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
  7. 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
  8. 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
  9. INFO 9/16/14 1:26 PM:liquibase: No changes found, nothing to do
  10. Liquibase 'generateChangeLog' Successful

Using Liquibase on Teradata 14.

I am able to use liquibase on SQL Server without problems. However, if I try it on Teradata 14 I get the error below. I downloaded the jdbc from Teradata and downloaded the latest liquibase teradata extension which is liquibase-terdata-3.0.jar

I don't get the meaning of the error message. It looks like it is looking at SQL Server because of "information_schema".

What am I missing?

D:\liquibase-3.2.2-binTeradata>liquibase  --changeLogFile=D_THTR_DM_S.xml genera
teChangeLog
Unexpected error running Liquibase: liquibase.exception.DatabaseException: com.t
eradata.jdbc.jdbc_4.util.JDBCException: [Teradata Database] [TeraJDBC 14.00.00.4
1] [Error 3802] [SQLState 42S02] Database 'information_schema' does not exist.

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:
  1. Schemas (include tables, views, procedures etc) with cross-dependencies
  2. Users for application servers and for batch processes (include received object grants and optionally synonyms)
Bottom line: cross dependencies mean that there is no way to install schemas using schema based "changelog.xml" files and fixed sequential order of installation.


Expectation for database installation procedure:
  1. first, DBA will create everything that is not application specific: schemas, users, tablespaces, system grants etc
  2. Liquibase installs "changelog.xml" (which contains all schemas of "logical database") with one run.
  3. for each next release Liquibase installs "changelog.xml" (which contains all schemas of "logical database") with one run.


Current situation / Issues with alternatives:
  1. 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.

  2. 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.

Do you have a liquibase.properties file that may be affecting the result?

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
Viewing all 2993 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>