Solving Eclipse/maven error : dependency/ a.b.c (managed from x.y.z)

If Eclipse/M2E reports a maven dependency version conflict, with message “managed from x.y.z” (ex : “jooq/ 3.7.1 (managed from 3.6.0)“), the conflicting dependency is defined by an ancestor of the current maven project (could be its parent, great-parent, great-great-parent, etc.).

For example, let’s say maven signals a dependency conflict for a spring-boot 1.3 application. Version 3.7.1 of the JOOQ library is used while you specified version 3.6.0 (which is a pain because JAVA 7 is targeted, while JOOQ 3.7.1 only supports JAVA 8).

The error returned by the SpringBoot application is :
[code]
java.lang.UnsupportedClassVersionError: org/jooq/SQLDialect :
Unsupported major.minor version 52.0
[/code]

JOOQ is used by a dependency of the spring-boot application. The main application itself has no reference to JOOQ.

Indeed :

  1. project A declares a maven dependency on JOOQ 3.6.0 :
    [code lang=xml]

    org.jooq
    jooq
    3.6.0

    [/code]
    datawarehouse-jooq-dependency
  2. project B declares a maven dependency on project A, and defines spring-boot-starter-parent as a parent
    In project B dependencies, Eclipse/M2E flags JOOQ as “version 3.7.1 (managed from 3.6.0)” while version 3.6.0 is expected.
    feedbackrestservices-jooq-dependecy
  3. spring-boot-starter-parent has spring-boot-dependencies as a parent, which itself manages dependencies for JOOQ
    spring-boot-dependencies-managed-dependencies-jooq
    [code lang=xml]

    org.jooq
    jooq
    ${jooq.version}

    [/code]

To fix it, you could add a jooq 3.6.0 dependency to project B, so that the maven dependency conflict solving strategy uses this version since it is the nearest dependency. But that would be ugly. A cleaner solution consists in overriding the jooq.version property defined in spring-boot-starter-parent, as documented here :
[code lang=xml] 3.6.0 [/code]

Using Amazon Redshift with Hibernate

Amazon Redshift is not designed for ORMs like Hibernate. However, it sometimes may be useful to let Hibernate manage a couple of tables. For example, we were automatically generating some large tables for big-data analysis, and wanted to store metadata about the generated structures in the same database, to keep them in sync. Hibernate seemed convenient to manipulate these metadata.

First, that’s not a good idea. Hibernate tends to generate a lot of useless queries, unless you take the time to properly tweak it, you’ll feel the pain of letting Hibernate query a RedShift server on the other side of the planet (close to 0.5 second for a “SELECT 1” query sent to the database…).

Then, you’ll notice that Redshift SQL may be based on Postgres, still not everything is working as expected. Especially, postgres serial type (identity columns) are not supported.

Eventually, you’ll find out there’s no way to retrieve the value of the last identity generated for a inserted row. That’s a serious issue knowing that hibernate requires a primary key to identify inserted objects.

But if you still crave using Hibernate with RedShift, once you’ll have downloaded the JDBC driver, you may want to use this (unperfect) Hibernate Redshift dialect to get you started :
[code lang=java]
import org.hibernate.dialect.PostgreSQL82Dialect;
import org.hibernate.id.IdentityGenerator;

public class RedshiftDialect extends PostgreSQL82Dialect {

@Override
public String getIdentitySelectString(String table, String column, int type) {
// There’s not method in the JDBC driver to retrieve the latest generated id.
// So try to retrieve the largest id, and pray for no concurrent access.
return “SELECT MAX(“+column+”) from “+table;
}

@Override
public String getIdentitySelectString() {
// Should never be called
return “SELECT 1 FROM PG_TEST”;
}

@SuppressWarnings(“rawtypes”)
@Override
public Class getNativeIdentifierGeneratorClass() {
return IdentityGenerator.class;
}

@Override
public String getIdentityColumnString( int type )
{
// replace the Postgres “serial” type with RedShift Vertica one
return “IDENTITY”;
}

@Override
public boolean hasDataTypeInIdentityColumn()
{
return true;
}
}
[/code]

How to fix Vertica error “Attempted to create too many ROS containers for projection” ?

While loading data into the HPE Vertica database, you may run into this issue :

[code lang=SQL]
[Vertica][VJDBC](2245) ERROR: Attempted to create too many ROS containers for projection x.y
[/code]

You may also notice that the error disapears if you wait a few minutes before restarting your data loading process. Only to reappear a little while later.

The issue comes from the vertica Read Optimized Store (ROS).

When loading data into Vertica, Continue reading

Monetdb : how to get schema and tables information ?

As other SQL database engines, monetdb allows to query schema and table information through SQL queries over a few system tables, namely : sys.schemas, sys.tables, and sys.columns.

The following query will give columns details for the system table “tables”:
[code lang=sql]
SELECT c.id, c.name, c.type, c.type_digits
FROM sys.columns c LEFT JOIN sys.tables t ON c.table_id = t.id
WHERE t.name = ‘tables’;
[/code]

The resultset :
[code]
+——+—————+———-+————-+
| id | name | type | type_digits |
+======+===============+==========+=============+
| 5211 | id | int | 32 |
| 5212 | name | varchar | 1024 |
| 5213 | schema_id | int | 32 |
| 5214 | query | varchar | 2048 |
| 5215 | type | smallint | 16 |
| 5216 | system | boolean | 1 |
| 5217 | commit_action | smallint | 16 |
| 5218 | access | smallint | 16 |
| 5219 | temporary | smallint | 16 |
+——+—————+———-+————-+
[/code]