Liquibase 4.9.1 with Netezza extension issue

I have been successfully using the Liquibase extension for Netezza with Liquibase 3.10.2 for quite awhile now.

(GitHub - inergynl/liquibase-netezza: A liquibase extension for Netezza.)

Now I am trying to get it to work with Liquibase 4.9.1. I know the extension is not supported by Liquibase, but I thought I give some additional details for the question I asked on the recent community meetup.

When I run the following Liquibase CLI for netezza, I’m getting: “Driver class was not specified and could not be determined from the url”:

./liquibase --username=nzuser --password=“XYZ” --classpath="/" --url=“jdbc:netezza://host:port/database” --changeLogFile=“db-changelog-master-netezza.xml” --logLevel=info update

Any idea on an easy fix for this issue, other than providing the --driver parameter?

UPDATE:

I tried adding “driver” property, and now I’m getting this error:

[2022-04-18 11:36:18] WARNING [liquibase.database] Unknown database: Netezza NPS
[2022-04-18 11:36:18] INFO [liquibase.database] Error getting default schema
liquibase.exception.DatabaseException: Error executing SQL call current_schema: ERROR:  'call current_schema'
error         ^ found "CURRENT_SCHEMA" (at char 6) expecting an identifier found a keyword
.
.
.
2022-04-18 11:36:33] INFO [liquibase.database] Set default schema name to null
[2022-04-18 11:36:33] INFO [liquibase.lockservice] Successfully released change log lock
[2022-04-18 11:36:33] SEVERE [liquibase.integration] ERROR:  CREATE TABLE: object "DATABASECHANGELOG" already exists.
 [Failed SQL: (0) CREATE TABLE DATABASECHANGELOG (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED datetime NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10))]


I was able to use the DBeaver extension successfully.

Our problem seems to be solved, but we will do more extensive testing.