Develop Reference

jooq 3.11.9 with MySQL Ver 8.0.11

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

Flyway 4.2.0 Multiple Nodes In Parallel Failure with Oracle 11g

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.

maxValue gives me an error in Mysql 5.6 but not in Mysql 5.1

Im running an old ETL program wrote in Java. that program worked ok when I stored data results into Mysql 5.1 using JDBC connector. But when I tried to store data in Mysql 5.6 I'm receiving the following error:
You have an error in your SQL Syntax: check the manual that corresponds
to your mysql server version for the right syntax use near
'maxValue = maxValue + 10 WHERE primaryKeyName = 'run_Id'' at line 1."
I checked mysql website and maxValue is a reserved word in version 5.6. and in version 5.1 (link: https://dev.mysql.com/doc/refman/5.5/en/keywords.html ) so it seems not a direct problem based on maxValue name in different mysql version.
I cannot understand why I'm receiving this error, additionally based on the fact that its a compiled program I don't have many code files to modify.
UPDATE----------
based on #wchiquito input i checked and in 5.1 is key but not reserved. anyone knows a turn around to surpass reserved words with legacy software?.

Batch update fails when connecting to an "old" column family with DataStax driver

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.

flyway commandline tool - what option to re-execute failed DDL?

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