Release-Version of liquibase-maxdb?

Liquibase Development
1

Hi, 


it’s been 5 months since the maxdb support was separated from the main module, but it’s still an unreleased 1.0.0-SNAPSHOT version.


Are there any plans to release it and to get it into the central maven repo?


Thanks and best regards,

Marc

2

Thanks for reminding me. I am working on improving my test infrastructure and the MaxDB release has fallen by the wayside during that.


I attached an updated snapshot against 3.1.1, are you able to test to make sure it works before I release it? I had to tack a “.txt” extension on to upload it.


Nathan

3

I committed that change. Otherwise is it working for you?

Nathan

4

I haven’t quite tested your version, but I’ve been experimenting around a bit, and MaxDB does not support “call current_schema”.  “SELECT CURRENT_SCHEMA FROM DUAL” should do the trick, like:



    @Override

    protected String getConnectionSchemaName() {

        DatabaseConnection connection = getConnection();

        if (connection == null) {

            return null;

        }

        try {

            ResultSet resultSet = ((JdbcConnection) connection).prepareCall(“SELECT CURRENT_SCHEMA FROM DUAL”).executeQuery();

            resultSet.next();

            return resultSet.getString(1);

        } catch (Exception e) {

            LogFactory.getLogger().info(“Error getting default schema”, e);

        }

        return null;

    }

 

Marc

5

Seems not enough, though, I get:

  2. Caused by: liquibase.exception.LockException: liquibase.exception.UnexpectedLiquibaseException: liquibase.snapshot.InvalidExampleException: Found multiple catalog/schemas matching null.MY_SCHEMA
  3. ... 82 more|
6

adding

     public boolean supportsSchemas() {

        return false;

    }


to MaxDBDatabase seems to do the trick.

7

It’s not necessary to overwrite getConnectionSchemaName() if supportsSchemas returns true? Nice to know and that part seems to work now. I’ve just fetched the latest change from github.


Using that latest version I now get 

  2. Caused by: liquibase.exception.LockException: liquibase.exception.UnexpectedLiquibaseException: Don't know how to query for sequences on MYSCHEMA @ jdbc:sapdb://maxdb001:7210/MAX
  3. <span class="Apple-tab-span" error... I'm checking what goes wrong there.
8

OK, I’m stuck. Our primary instance works (with supportSequence() returning false), but I can’t get rid of the 



9

Thanks, I created https://liquibase.jira.com/browse/CORE-1859 to track the issue.


You are right that the extension shouldn’t break the core functionality. I’ll look into it. Thanks for the test case.


Nathan

10

It is working with MaxDB, but strangely enough it’s breaking Derby.


We have a setup where we test some functionality against a Derby DB. Productively we’re running against MaxDB (and should migrate to HANA soon.).


Liquibase core 3.1.1 works fine with the local Derby database. Adding the MaxDB extension (current master, e485362) works fine with MaxDB, but the tests break with “ERROR 42X01: Syntax error: Encountered “BYTE” at line 1, column 114.”


I’ve traced that down to the DataTypeFactory which just has a prioritised list of implementations, but ignores the actual database. So it actually picks the BlobTypeMaxDB to ultimately generate the SQL statements for Derby.


I’ve attached a small test case. If you run that in maven it will fail with the same error as mentioned above. Remove the liquibase-maxdb extension from the pom and it’ll work fine (but that’s not a good option for us). 


I’ve also included a small patch for liquibase-core that fixed that problem (at least for me & this specific case). 


I was rather surprised that adding the extension breaks core functionality, that’s not really intended, is it? I’m not sure I fully understand the priority handling, but ignoring the actual database feels odd to me.


Thanks and best regards,

Marc

11

OK, thanks. If that can be fixed within liquibase-core then the extension is fine as far as I can tell.


BTW: will that really be 3.2.0 or rather 3.1.2? For easier consumption on our side I’d favour the micro-change (threes some legal stuff that we have to go through for even minor version increases…)


Thanks,

Marc