Quantcast
Channel: Liquibase Forums
Viewing all 2993 articles
Browse latest View live

updateDatabase ant task expected the changelogfile to be in file system

$
0
0
Hi,

I have upgraded the liquibase from 2.0.5 to 3.3.1

In the old version the Ant task "updateDatabase" took the  changelogfile  relatively to the classpath (in my case : META-INF/database/root.changes.xml)

Now,  it is looking for the file relatively to the file system folder and it fails.

Is any way to tell to Ant task "updateDatabase" to load changelogfile   relatively to the classpath? 


Thx
Evgeny


Re : updateDatabase ant task expected the changelogfile to be in file system

$
0
0
All files are checked relative to the basedir of the Ant file unless they are given an absolute path. Where is the change log file located? Is it in a jar file or is it sitting in a folder in your project structure?

Re : updateDatabase ant task expected the changelogfile to be in file system

$
0
0
It is in a jar and in 2.0.5 it worked

Re : Looking for Feedback on Liquibase 4.0 Roadmap

$
0
0
There was apparently some Zoho issues which led people to reply directly to me rather than post to the forum. Hopefully it's cleaned up. I'm going to summarize some and add more thoughts here rather than duplicating it to everyone.

All Database Implementations As Plugins
The idea of pushing all database implementations to plugins seemed well received and I agree makes sense. That is something we will do for 4.0. We'll want to have an easily extendable abstract base in liquibase-core and probably UnknownDatabase but the rest will go to sub-modules.

One thing that would help would be sort of an "SDK Test Suite" that can be ran against any database extension to make sure it generally works and also follows whatever conventions make sense. We should develop this suite along with 4.0.

3rd Party Libraries
- JCommander was suggested over commons-cli. I haven't looked at JCommander before but will.

- Guice was suggested for dependency injection, in part because spring is too heavyweight and more likely into version problems. This is a very good suggestion, I haven't really looked at Guice (have just used Spring) but the version issues was a reason I wasn't really wanting to use Spring. Classloading edge-cases continues to be a huge headache with 3.3.x so I'm all for a DI library that may help that. I looked quickly at Guice and it would probably work well. I'll continue to look at Guice

- No love for OSGi. It definitely brings its own issues and I agree that it probably isn't the right tool for handling our dependency management. We should support plugging into OSGi well but shouldn't be building off it.

Multiple Connections

Several people liked this feature. Definitely something to ensure is supported.

Java 6 Support: Why Still?
I try to ensure Liquibase can run in as many places as possible. That is why I've kept dependencies to a minimum and also build off old Java versions. However, at some point it is time to move on. 

I had tried to look for stats on Java versions being used in and couldn't find anything great. After some digging it semed like there was maybe still 20-30% of projects still running Java 6 which seemed enough of an install base to continue supporting it. If someone has better statistics, let me know though.

"Verified Test" Framework
I just spun the verified test framework off as a separate project (http://testmd.org) so it can grow independently and/or make dependency management cleaner in Liquibase. Take a look and let me know what you think.

Scope Objects
"Are they Necessary?" "Are they Like ServletRequest?" "Consider making them TreadLocal" "Just use @Inject"

I'm still working through how to best handle the Scope object. If we use Guice, that may remove a lot (all?) of the need for it. But perhaps not as well. They do sort of behave like ServletRequest, especially its "get|setAttributes" methods.

What I want to do with Scope is to have a way for new configuration and other state objects to be managed without impacting the existing code. This is partly to keep backwards compatibility but also because we want extensions to be able to define new attributes that liquibase-core does not know about and they can simply flow though everything. 

For example, liquibase-core may define a "connection" object which is normally used for reading/writing to the database but someone may want to attach a new "backupConnection" to the scope when they start their command and then in one of their extension Change classes they can use that connection to backup data before dropping a table. 

@Inject may work for that, but I think a more contained Scope object would work better. 



Short-Term Roadmap

I think the first steps toward 4.0 are:
  • New v4.0 branch [done]
  • Split off TestMD [done]
  • Guice and/or Scope object
    • Will be used by snapshot/action logic
  • Refactor Snapshot Logic / "Action" Logic
    • Includes splitting out databases to sub-modules
    • Use TestMD for testing it all
    • Big project but all wrapped together enough that it would probably be a mess to do in stages

Thoughts? (Assuming Zoho lets you post :)  )

Nathan

Guice Evaluation

$
0
0
I started looking into Guice and how we could use it with Liquibase 4.0. After some research, I think it will not be enough of a help to introduce as a dependency. We need a way to support different subclasses of objects being used at runtime, and while the Guice @Inject support is nice I don't think it fits well enough with what we need. What we mainly need is a good way to manage implementations which can be easily overridden with better implementations, but that logic can be complex and isn't necessarily known at "bind" time. 

For example, Liquibase ships with a bunch of Database implementations--one UnknownDatabase which supports all databases, and an implementation for each supported database that works better for that database. Furthermore, extensions can add new Database implemenatations and can override standard ones with even better implemenations (such as a new OracleDatabase that handles quoting based on customer-specific needs). When we connect to a database we need to find the right Database implementation based on the connection URL, connection version metadata etc. I'm not seeing how the Guice bind logic would be able to handle this. 

Another example: there are the Change implementations which each have a name like "addTable". Extensions can also provide better "addTable" implementations. When we are parsing a changelog we aren't injecting Change instances to have Guice help with that, we need to look up the ones that can match and then find the best match.

Final example: the *SQLGenerator classes each can support a combination of Database+Statatement to generate the correct SQL to do a Change. We want to look up the correct SQLGenerator, but we don't know what it is until we have the actual Statement and Database and we need to create one for each Statement.

There are similar examples with changelog parsers, diff logic, lock logic, changelog history logic, preconditions, etc. 

Guice seems to work well when are wanting to construct a graph of objects and at graph construction time you know the pieces/dependencies you are going to use. For us, most of the dependency management is happening after objects have been created.

Another thing I was hoping to get out of Guice was a solution to the bugs related to classes not being found in different classloader setups. When jars are nested in other jars in wars, or stored on a network location, or running in OSGi etc. the existing ServiceLocator logic can break and be a pain to troubleshoot. Unfortunately Guice doesn't seem to have any sort of Class Finding logic. I can understand it being out of scope of the project, I was just hoping it wasn't...



Therefore, I'm feeling like the best approach for us is to stick with our more build-your-own extension manager than using Guice. We'll still need the ServiceLocator logic to find implementations of classes at startup which populate the various ChangeFactory etc. classes which can use whatever logic they want to iterate over the found classes/instances to find what is needed. 

Once change I am planning on making, however, is to manage that whole process better with the Scope object. Rather than global singletons, I would like to move the Factory etc. objects onto Scope-based singetons. So, instead of ChangeFactory.getInstance() you would call scope.get(ChangeFactory.class). This will give us some of the no-singleton advantages of Guice, even if it isn't auto-setting dependencies. 

Am I missing anythign in my Guice evaluation?

Nathan

Re : Looking for Feedback on Liquibase 4.0 Roadmap

Liquibase 3.2.2 :: DefaultLogger output to error

$
0
0
I would like to know why the DefaultLogger is using error output by default.

  1. public class DefaultLogger extends AbstractLogger {

  2.     private String name = "liquibase";
  3.     private PrintStream err = System.err;
  4.     ....
  5.  protected void print(LogLevel logLevel, String message) {
  6.         if (StringUtils.trimToNull(message) == null) {
  7.             return;
  8.         }

  9.         err.println(logLevel + " " + DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT).format(new Date()) + ": " + name + ": " + buildMessage(message));
  10.     }
There is a reason for that ? why not system.out ?

Thanks in advance,

addColumn problem

$
0
0

I am having a strange problem when trying to add a new column to a database.


If have changeset that has the following property details

  1.     <property name="boolean.type" value="boolean" dbms="postgresql, hypersql, hsqldb"/>
        <property name="boolean.type" value="bit" dbms="mysql"/>
        <property name="boolean.type" value="smallint" dbms="derby"/>
        <property name="boolean.type" value="numeric(1)" dbms="oracle"/>


Now if I use the following

  1. <changeSet author="UnicentaOpos - John L" id="Create Categories Table">
     <preConditions onFail="MARK_RAN">
        <not>
          <tableExists tableName="CATEGORIES"/>
        </not>
     </preConditions>
  2.     <createTable tableName="CATEGORIES">
         <column name="ID" type="varchar(255)">
             <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="NAME" type="varchar(255)">
             <constraints nullable="false"/>
            </column>
            <column name="PARENTID" type="varchar(255)"/>
            <column name="TEXTTIP" type="varchar(255)" defaultValue="NULL"/>
            <column name="CATSHOWNAME" type="${boolean.type}" defaultValueBoolean="true">
             <constraints nullable="false"/>
            </column>
            <column name="IMAGE" type="${blob.type}"/>
       </createTable>
  3. </changeSet>


The table is created ok, but

If a do the following to add the CATSHOWNAME column when it does not exist.

  1.  <addColumn tableName="CATEGORIES">
            <column name="CATSHOWNAME" type="${boolean.type}" defaultValueBoolean="true">
             <constraints nullable="false"/>
            </column>
     </addColumn>


I get the error that that smallint can hold the value of type Boolean.

Does any one have any Ideas why this is happening.

Thanks



Re : Liquibase 3.2.2 :: DefaultLogger output to error

$
0
0
The main reason is to separate log messages from "normal" output when running commands like updateSql which writes the SQL to stdout. If they both went on the same channel the file you get from running updateSql > file.sql would not be valid SQL.

Nathan

Re : SQL Anywhere 12

$
0
0
Hello,

I realize that this is a very old thread, but I am providing an update for others who may be searching for further information about using Liquibase and SAP SQL Anywhere (previously known as "Sybase Adaptive Server Anywhere" or "ASA") together.

---

A side note that this topic has also been discussed further on the SQL Anywhere forums: http://sqlanywhere-forum.sap.com/questions/7786/using-with-liquibase-driver-not-capable

This issue has only been found with SQL Anywhere in Liquibase 2.x versions and is resolved in Liquibase 3.x versions.

A work-around for Liquibase 2.x versions would be to amend the JDBC connection URL to include an additional SQL Anywhere connection option that will prevent the exception - e.g.:
    
   jdbc:sqlanywhere:uid=dba;pwd=sql;eng=demo; PreventNotCapable=y


Jeff Albion

Pull request for Action class refactoring

Re : Liquibase 3.2.2 :: DefaultLogger output to error

$
0
0
Hi Nathan,

I understand the approach, but maybe it is a better idea to do it configurable ?

We are using a tool that run Liquibase script in a shell script, and because it is running the output in error, looks like it is failing all the time, when it is not.

Thanks in advance,

Output to sql fails after upgrading to liquibase 3.3.1 from 2.0.5

$
0
0
Hi,

We have recently upgraded Liquibase to 3.3.1 from 2.0.5.

We have clients using older versions of our products, which had Liquibase 2.  So the Liquibase checksums in their databases are in the format of Liquibase 2.

Now, we want to upgrade those clients using Liquibase 3. If we update their database normally, it works fine. However, if we output the result to a file, we get the following error :

liquibase.exception.ValidationFailedException: Validation Failed:
     187 change sets check sum
          META-INF/database/changes.xml::Manually create the hibernate auto-increment table for OO::hibernate is now: 7:6389ca4eac535728ac03577c0f06a463
          META-INF/database/broker.changes.xml::create OO_BRANCH_CONTEXTS::engine is now: 7:cdcaae1028f4deba560bede80ef09fce
          META-INF/database/broker.changes.xml::create OO_RUNNING_EXECUTION_PLANS::engine is now: 7:6fbb735ac3f58e8677c9182f896d74cd

(and so on)


This is what we ran (please excuse the Groovy syntax):

ant.updateDatabase(
                url: dbProperties.getProperty("jdbc.url"),
                driver: dbProperties.getProperty("jdbc.driver_class"),
                username: dbProperties.getProperty("db.username"),
                password: decryptedPass,
                classpathref: "driver-classpath",
                changelogfile: changesFile,
                labels: "",
                outputfile: outputFilePath);

Again, if we run this without the "outputfile: outputFilePath" part, it works fine.

What gives?

Note that we don't want to clear the existing checksums of Liquibase 2, because we do want the validation.

Thanks, Vova

Liquibase update from java code gives ChangeLogParseException

$
0
0
In a ConfigServlet (part of a Maven project) a liquibase update is started. Sinds version 3.2.0 there's an exception thrown:

  1. Caused by: liquibase.exception.ChangeLogParseException: Error Reading Migration File: Found 2 files that match liquibase/root.changelog.xml
  2. at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:112)
  3. at liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:17)
  4. at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:215)
  5. at liquibase.Liquibase.update(Liquibase.java:192)
  6. at liquibase.Liquibase.update(Liquibase.java:181)
  7. at nl.procura.inn.web.servlets.ConfigServlet.updateDb(ConfigServlet.java:125)
  8. ... 14 more
  9. Caused by: java.io.IOException: Found 2 files that match liquibase/root.changelog.xml
  10. at liquibase.util.StreamUtil.singleInputStream(StreamUtil.java:189)
  11. at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:93)
  12. ... 19 more
I'm using Netbeans 8.0.2 (on Windows 7) running my web application. And that's seems to be the problem. When I deploy the war-file myself by copying this file into my Apache Tomcat server (version 7.0.57), no exception is thrown.
Also when I run the application by Netbeans but deleted my liquibase folder (with the changelog files) in the target directory (target/classes/liquibase) no exception is thrown. This target directory is of a different maven module than that of my web application.

While writing about this issue, I found out that my configuration of JRebel (version 6.0.2) caused the problem. Possibly JRebel added the target directory to my classpath somehow. By changing the configuration by just using the JRebel panel everything works fine again.

Unfortunately, it took me a lot of time to find the cause. Hopefully others with the same problem find this post.

Using Liquibase 3.3.2 with Vertica 7.1 : java.lang.NoSuchMethodError: liquibase.snapshot.JdbcDatabaseSnapshot$CachingDatabaseMetaData.getTables

$
0
0
Hello,
I'm trying to use the new liquibase version 3.3.2 with vertica extension 1.2 (got from here : https://liquibase.jira.com/wiki/display/CONTRIB/Liquibase+Vertica+Extension) but I have the following exception :
  1. DEBUG 1/13/15 10:47 AM: liquibase: Connected to VDDBADEV2@jdbc:vertica://vip-farm-f5-dv_shr00:5433/DV_SHR00
    DEBUG 1/13/15 10:47 AM: liquibase: Setting auto commit to false from true
    DEBUG 1/13/15 10:47 AM: liquibase: Computed checksum for 1421142460847 as 14c3e43bd079e3a70467fbcc7b24a2ae
    Unexpected error running Liquibase: liquibase.snapshot.JdbcDatabaseSnapshot$CachingDatabaseMetaData.getTables(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)Ljava/util/List;

    SEVERE 1/13/15 10:47 AM: liquibase: liquibase.snapshot.JdbcDatabaseSnapshot$CachingDatabaseMetaData.getTables(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)Ljava/util/List;
    java.lang.NoSuchMethodError: liquibase.snapshot.JdbcDatabaseSnapshot$CachingDatabaseMetaData.getTables(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)Ljava/util/List;
            at liquibase.ext.vertica.snapshot.TableSnapshotGeneratorVertica.snapshotObject(TableSnapshotGeneratorVertica.java:46)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:60)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.jvm.JdbcSnapshotGenerator.snapshot(JdbcSnapshotGenerator.java:63)
            at liquibase.snapshot.SnapshotGeneratorChain.snapshot(SnapshotGeneratorChain.java:50)
            at liquibase.snapshot.DatabaseSnapshot.include(DatabaseSnapshot.java:163)
            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:134)
            at liquibase.snapshot.SnapshotGeneratorFactory.has(SnapshotGeneratorFactory.java:88)
            at liquibase.snapshot.SnapshotGeneratorFactory.hasDatabaseChangeLogLockTable(SnapshotGeneratorFactory.java:166)
            at liquibase.lockservice.StandardLockService.hasDatabaseChangeLogLockTable(StandardLockService.java:139)
            at liquibase.lockservice.StandardLockService.init(StandardLockService.java:85)
            at liquibase.lockservice.StandardLockService.acquireLock(StandardLockService.java:188)
            at liquibase.lockservice.StandardLockService.waitForLock(StandardLockService.java:154)
            at liquibase.Liquibase.update(Liquibase.java:186)
            at liquibase.integration.commandline.Main.doMigration(Main.java:1044)
            at liquibase.integration.commandline.Main.run(Main.java:175)
            at liquibase.integration.commandline.Main.main(Main.java:94)

Is there any new version of the vertica extension incoming soon, compatible with 3.3.2 of Liquibase ?

Regards,
Mohamed.




Re : FILENAME column in databasechangelog table.

$
0
0
Hi Nathan,

Any feedback on this further?

Thanks.

YAML update fails with Unexpected error running Liquibase: java.util.LinkedHashMap cannot be cast to java.util.List

$
0
0
JDK: 7u67
Running on MacOSX with Mavericks
Liquibase 3.3.2
SnakeYaml 1.13 (also tried 1.12 and 1.14)
MySQL Connector: mysql-connector-java-5.1.34.jar

Running from command line I created a changelog using:
./liquibase --changeLogFile test.yaml generateChangeLog

Now when I set to a new database and run update:
./liquibase --changeLogFile test.yaml update

I get this error:
Unexpected error running Liquibase: java.util.LinkedHashMap cannot be cast to java.util.List

test.yaml content below here:
databaseChangeLog:
  changeSet:
    id: 1421340276226-1
    author: myname (generated)
    changes:
    - createTable:
        columns:
        - column:
            autoIncrement: true
            constraints:
              constraints:
                primaryKey: true
            name: id
            type: BIGINT
        - column:
            constraints:
              constraints:
                nullable: false
            name: fname
            type: VARCHAR(255)
        - column:
            constraints:
              constraints:
                nullable: false
            name: lname
            type: VARCHAR(255)
        tableName: person

A single user for all schemas?

$
0
0
We're a fairly large shop, and we use liquibase via maven. As we add more and more schema, we have to add every single schema user to the settings.xml for each one of the test environments (currently ten of them), which is getting unwieldy. The settings.xml file for our main build user is almost at 4,000 lines.

So I was wondering if anyone has come up with a good way to use a single user to write to many schemas in Oracle, without giving that one user permissions for sys/system tables. Basically, a release user that is not an su.

It looks like we could use the "liquibaseSchemaName" setting to set the changelog table to still be within each schema, but it;s the authentication that I'm unsure about.

Has anyone done this already?

Re : Liquibase 3.2.2 :: DefaultLogger output to error

$
0
0
It would be good to be more configurable. I'm working on how logging works in general with Liquibase 4.0 and will try to improve the options.

Nathan

liquibase Diff command Using difftypes=data is not working.

$
0
0
c:\LiquiBase>liquibase --username=root --url=jdbc:mysql://localhost:3306/schema3 --driver=com.mysql.jdbc.Driver --referenceUrl=jdbc:mysql://localhost:3306/solut ion --referenceUsername=root --diffTypes=data diff diffChangeLog >change.xml

I have created two databases in mysql, out of two one contains tables with data and another contains only empty tables. I expect from above command it should given the difference of data and generate the changelog.But it is not giving data diff it is just giving the structure difference.
Viewing all 2993 articles
Browse latest View live


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