I successfully ran v1 migration with a create table DDL. I copied same to v2 file and ran - got the expected validation error message:
Migrating to version 1.0.002
com.googlecode.flyway.core.exception.FlywayException: Error executing statement
at line 1: create table people(id number(10) primary key, name varchar2(301))
Caused by java.sql.SQLSyntaxErrorException: ORA-00955: name is already used by a
n existing object
MigrationException: Migration to version 1.0.002 failed! Please restore backups
and roll back database and code
I corrected the v2 file and ran flyway migrate again. Giving back the error message
Current schema version: 1.0.002
MigrationException: Migration to version 1.0.002 failed! Please restore backups
and roll back database and code
I am not in a stage where a database backup is taken - simple trying to execute a fixed DDL. I don't currently see a solution short of flyway clean. Why cannot flyway try to execute FAILED versions again (if the checksum has changed)? Or shouldn't there be a flyway rollback command?
I know I can very well modify the code to make it that way, but was there any reason why you chose it to behave this way?
The problem with simply reexecuting is that some changes might already have been applied, which will cause the migration to fail.
There are two solutions to this:
Use a database that supports DDL transactions such as PostgreSQL, SQLServer or DB2
Perform a manual cleanup of the modified structures and the metadata table before reapplying
Related
We are in the process of upgrading our database version from DB2 11.1.3 to DB2 11.5.6. We have been using Flyway for 4 years for migrating our code. The version we are using is 5.1.3 and it is working well, except it throws a warning the DB2 11.5 is not supported.
I have downloaded and tried to use Flyway 7.13.0 and 7.15.0 in our process but they both throw the following error
ERROR: Unable to obtain connection from database (jdbc:db2://VAN-FCALLANDER:50000/TMLCLCUR:retrieveMessagesFromServerOnGetMessage=true;) for user 'TMWIN': [jcc][10214][10050][4.29.24] java.util.Properties object passed to java.sql.Driver.connect() cannot be overridden by URL: jdbc:db2://VAN-FCALLANDER:50000/TMLCLCUR:retrieveMessagesFromServerOnGetMessage=true;. ERRORCODE=-4461, SQLSTATE=42815
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL State : 42815
Error Code : -4461
Message : [jcc][10214][10050][4.29.24] java.util.Properties object passed to java.sql.Driver.connect() cannot be overridden by URL: jdbc:db2://VAN-FCALLANDER:50000/TMLCLCUR:retrieveMessagesFromServerOnGetMessage=true;. ERRORCODE=-4461, SQLSTATE=42815
Caused by: com.ibm.db2.jcc.am.SqlSyntaxErrorException: [jcc][10214][10050][4.29.24] java.util.Properties object passed to java.sql.Driver.connect() cannot be overridden by URL: jdbc:db2://VAN-FCALLANDER:50000/TMLCLCUR:retrieveMessagesFromServerOnGetMessage=true;. ERRORCODE=-4461, SQLSTATE=42815
According to IBM, the error being returned is from the way the parameter is set by Flyway. https://www.ibm.com/docs/en/db2/11.5?topic=errors-errorcode-4461
I have tried using both the 11.1 (type3) driver and the 11.5 (type4) driver and both are throwing the same message.
Any idea how to get around this without updating the actual Flyway code the way IBM suggests?
Looks like the Flyway code may need some change.
Check their issues page and open a ticket if a ticket does not already exist there.
Otherwise there are possible workarounds for now.
In your specific case, the attribute appended to the URL triggers the exception so you can try:
(1) Change the flyway.url to remove :retrieveMessagesFromServerOnGetMessage=true
(2) Change the flyway config to supply this property via the fltway.jdbcProperties (or equivalent method) if that is enabled in your flyway version: flyway.jdbcProperties.retrieveMessagesFromServerOnGetMessage=true . See docs
https://flywaydb.org/documentation/configuration/parameters/jdbcProperties
or
(3) externally configure the connection property that you need via the IBM db2dsdriver.cfg. See the IBM Db2 documentation for details. The idea is that you can put all (or some of) the Data Source Name details and parameters into an XML file (db2dsdriver.cfg) and the Db2 driver will parse that at runtime to carry out your instructions.
or
(4) remove the property from the URL and suffer the absence of detailed messages on errors until the flyway code gets fixed.
I am using jooq version 3.11.9 and I have MySQL Ver 8.0.11 installed on my local. While initiating connection of jooq with Mysql I get the following error:
org.jooq.exception.DataAccessException: SQL [select 1 as `one` from dual where exists (select 1 as `one` from `mysql`.`proc`)]; Table 'mysql.proc' doesn't exist
I understand MySQL Ver 8.0.11 doesn't contain this table. So what is the solution? I cannot downgrade the MySQL versions as other projects are already running with this version.
As you can see in the mysql Release notes:
Previously, information about stored routines and events was stored in the proc and event tables of the mysql system database. Those tables are no longer used. Instead, information about stored routines and events is stored in the routines, events, and parameters data dictionary tables in the mysql system database. The old tables used the MyISAM (nontransactional) storage engine. The new tables use the InnoDB (transactional) engine.
That query is there precisely to check whether you're running on MySQL 8+. It should not cause an error or even a stack trace (but maybe a debug message). You can safely ignore it.
If you found an error or stack trace message, or if this causes your code generation to fail, it might be a bug in jOOQ's logging configuration, which I would invite you to file here: https://github.com/jOOQ/jOOQ/issues/new
I have multiple application servers configured to run flyway at startup. Each server attempts to apply the same set of migrations across multiple schemas in the same Oracle 11g database. These servers are started at the same time. This works most of the time. On occasion, however, a server fails during migration because it encounters a unique constraint violation.
Unable to insert row for version '0' in metadata table "FOO"."SCHEMA_VERSION"
SQL State : 23000
Error Code : 1
Message : ORA-00001: unique constraint (FOO.SCHEMA_VERSION_pk) violated
at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addAppliedMigration(MetaDataTableImpl.java:242)
at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addBaselineMarker(MetaDataTableImpl.java:334)
at org.flywaydb.core.internal.command.DbBaseline$2.call(DbBaseline.java:135)
at org.flywaydb.core.internal.command.DbBaseline$2.call(DbBaseline.java:112)
at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
at org.flywaydb.core.internal.command.DbBaseline.baseline(DbBaseline.java:112)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:990)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:971)
at org.flywaydb.core.Flyway.execute(Flyway.java:1464)
at org.flywaydb.core.Flyway.migrate(Flyway.java:971)
...
I thought that flyway would be able to handle this situation based on the following:
https://flywaydb.org/documentation/faq#parallel
Shouldn't a flyway instance detect that the schema version table is locked and move onto the next schema?
Is there a setting that can ensure the schema version is locked or is this a bug?
The OracleTable class locks the table in exclusive mode. Should it add the NOWAIT clause and handle any resulting Oracle exception?
It should work. We test this with every build and the behavior without NOWAIT is the one we desired (block until lock is released). If you can reliably reproduce this or see a clear mistake in our code, then please by all means do file a bug with the necessary details in the issue tracker.
I'm running a PostgreSQL database migrated via Flyway. The initial script contains this sequence:
CREATE SEQUENCE hibernate_sequence
START WITH 1
INCREMENT BY 1000
NO MINVALUE
NO MAXVALUE
CACHE 1;
The migration runs fine.
Now I want to run some tests against my system, using an in-memory HSQLDB as the test setup. I connect to this HSQLDB using Postgres syntax already:
dataSource.setUrl("jdbc:hsqldb:mem:mydb;sql.syntax_pgs=true");
But I still get this error while the migration script runs:
Caused by: org.hsqldb.HsqlException: unexpected token: CACHE : line: 6
I suspect that this setup isn't possible, as the HSQLDB documentation doesn't mention a CACHE option (as PostgreSQL does). Is this true? Is there any workaround, maybe in using some other syntax or something?
Thanks a lot
I have a Cassandra process that was created and defined in early Cassandra versions. So far, we used an hector driver to connect to it. Im in a process of changing the driver to DataStax to enjoy the CQL new features and to allow asynchronous access.
I encounter some problems in the process of doing that transition. I've read this upgrade guide which shed some light though I still encounter some problems.
The biggest one is that I cant access the keyspace with a protocol version bigger than one. When I try the following python code:
cass4 = Cluster(['MyIp'])
cass4.protocol_version = 2
session = cass4.connect('myKeySpace')
This code yields the following errors and warnings:
ERROR:cassandra.connection:Closing connection <AsyncoreConnection(4849045328) IP:9042> due to protocol error: code=000a [Protocol error] message="Invalid or unsupported protocol version: 2"
WARNING:cassandra.cluster:Downgrading core protocol version from 2 to 1 for IP
WARNING:cassandra.metadata:Building table metadata with no column meta for keyspace
With the Java driver, I simply get a NoHostAvailableException: All host(s) tried for query failed connection error if im trying to connect with a protocol version bigger than 1.
This connection problem is causing me a lot of trouble building an appropriate Java DAO. for example, if Im trying to do batch update, e.g.:
BatchStatment batch = new BatchStatement()
batch.add(somePreparedStatement)
cqlSession.executeAsync(batch)
I get the following error:
com.datastax.driver.core.exceptions.UnsupportedFeatureException: Unsupported feature with the native protocol version 1 (which is currently in use): Protocol level batching is not supported
Running a "BEGIN BATCH.." operation directly on a cluster node using cqlsh works, So I know this CQL command can be executed, but I dont know how to prepare it in Java and execute it with protocol version 1. Also, the cassandra and CQL version an the cluster seems appropriate:
[cqlsh 3.1.7 | Cassandra 1.2.13.2 | CQL spec 3.0.0 | Thrift protocol 19.36.2]
So, questions are:
Why is this happening?
Can I connect to that keyspace with a protocol version greater than 1?
If not, Can I somehow bypass this batch update problem?
The answer for this issue was eventually found here:
Can I combine Batches and PreparedStatements?
Starting with Cassandra 2.0 and the corresponding versions of the C#,
Java, and Python drivers, PreparedStatements can be used in batch
operations (nb before that you could still prepare a complete batch
operation, but you’d need to know apriori the number of statements
that will be included).
Since my Cassandra version is 1.2xx, I cant use batch updates and prepared statements.
A work around is to create the query as a string (Ya, that's dirty) and than execute the string query.