Virtual graph on Stardog-6.1.1 from Denodo 7

We have a virtual graph accessing a virtual database in Denodo 6. We need to migrate it to Denodo 7 so we put the Denodo 7 drivers on $STARDOG_EXT and we have a question and we are facing an issue.


Both drivers Denodo 6 JDBC driver and Denodo 7 JDBC driver have the same class name:

$ jar -tvf denodo-vdp-jdbcdriver.jar| grep "jdbc.Driver.class"                                                                            
   310 Mon Dec 19 17:57:24 CET 2016 com/denodo/vdp/jdbc/Driver.class
$ jar -tvf denodo7-vdp-jdbcdriver.jar| grep "jdbc.Driver.class"
   233 Fri Mar 30 06:39:22 CEST 2018 com/denodo/vdp/jdbc/Driver.class

How Stardog knows which one to pick up if we can only define the jdbc.driver property?


When adding the virtual graph virtualg
default.mapping.include.tables=table1, table2, table3

via the command

$stardog-admin virtual add -u stardog_user --verbose

Password for user stardog_user:

and we get the exception

com.complexible.common.base.Pair cannot be cast to java.lang.Comparable
The detailed stack trace for the error is:
com.complexible.stardog.protocols.http.client.BaseHttpClient$HttpClientException: com.complexible.common.base.Pair cannot be cast to java.lang.Comparable
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.checkResponseCode(
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.execute(
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.executeHttpPost(
	at com.complexible.stardog.protocols.http.client.BaseHttpClient.executeHttpPost(
	at com.complexible.stardog.protocols.http.client.HttpVirtualGraphAdminConnectionImpl.addOrUpdate(
	at com.complexible.stardog.protocols.http.client.HttpVirtualGraphAdminConnectionImpl.addGraph(
	at com.complexible.stardog.virtual.cli.VirtualGraphAdd.performSecure(
	at com.complexible.stardog.cli.CLIBase.execute(
	at com.complexible.stardog.cli.admin.CLI.main(

Is this something related to stardog-6.1.1?

Note: The connection to the same Denodo 7 virtual database via a regular workbench (e.g. DBeaver) is doable.

Hi Manuel,

We do not currently support jar-qualified access to JDBC drivers. Due to the ambiguity introduced by including the same class multiple times in the classpath, you will need to avoid this. However, JDBC drivers are often backward compatible with previous server versions. Is it possible to use the Denodo 7 driver with the Denodo 6 server?

Regarding the error, can you please share the error from the server log?


Hi Jess,

I already tried the Denodo 7 driver to connect a Denodo 6 server but unfortunately it doesn't work.

java.lang.RuntimeException: java.sql.SQLException: connection error: Trying to connect to an unsupported Denodo version

Anyways, the migration to Denodo 7 is mandatory so the access to the Denodo 6 one won't be possible.

The full exception that I found on $STARDOG_HOME/stardog.log is:

ERROR 2019-03-25 17:42:57,149 [stardog-user-2] com.complexible.stardog.virtual.DefaultVirtualGraphRegistry:createVirtualGraph(256): Cannot initialize virtual graph discovery
java.lang.ClassCastException: com.complexible.common.base.Pair cannot be cast to java.lang.Comparable
        at java.util.Comparators$ ~[?:1.8.0_161]
        at java.util.TimSort.countRunAndMakeAscending( ~[?:1.8.0_161]
        at java.util.TimSort.sort( ~[?:1.8.0_161]
        at java.util.Arrays.sort( ~[?:1.8.0_161]
        at java.util.ArrayList.sort( ~[?:1.8.0_161]
        at$RefSortingSink.end( ~[?:1.8.0_161]
        at$ChainedReference.end( ~[?:1.8.0_161]
        at$AbstractWrappingSpliterator.fillBuffer( ~[?:1.8.0_161]
        at$AbstractWrappingSpliterator.doAdvance( ~[?:1.8.0_161]
        at$WrappingSpliterator.tryAdvance( ~[?:1.8.0_161]
        at java.util.Spliterators$1Adapter.hasNext( ~[?:1.8.0_161]
        at ~[guava-26.0-jre.jar:?]
        at ~[guava-26.0-jre.jar:?]
        at ~[guava-26.0-jre.jar:?]
        at com.complexible.stardog.virtual.vega.mapping.MappingGenerator.validateFkRefs( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.mapping.MappingGenerator.generateTriplesMaps( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.generateMappings( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsVirtualGraphFactory.create( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.vega.rdbms.RdbmsVirtualGraphFactory.create( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.createVirtualGraph( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.createVirtualGraph( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.add( ~[stardog-virtual-core-6.1.1.jar:?]
        at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.addVG( ~[stardog-virtual-protocols-http-server-6.1.1.jar:?]
        at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.add( ~[stardog-virtual-protocols-http-server-6.1.1.jar:?]
        at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5( ~[stardog-protocols-http-server-6.1.1.jar:?]
        at [shiro-core-1.2.3.jar:1.2.3]
        at [shiro-core-1.2.3.jar:1.2.3]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:1.8.0_161]



Hi Jess,

did you have chance to have a look at this exception?



It appears as though you will probably need to manually handle your classpath during the migration such that the 6 drivers are the only ones in the classpath when using verison 6, and the 7 drivers are the only ones there for 7, since their 7.x drivers are clearly incompatible with version 6

The exception is caused by unresolved foreign keys when auto-generating the mappings. This typically happens when foreign keys are in schemas not listed in the sql.schemas option. The error message is not helpful and this has been fixed in the upcoming release.

Thanks Jess,

the way I created the mapping was by first creating a DM with some tables in the default.mapping.include.tables option and then doing some customisations. This was working with the Denodo6 driver.

Might this cause this issue with the Denodo7 driver?

Is there a workaround?



This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.