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.
Question
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?
Issue
When adding the virtual graph virtualg
parser.sql.quoting=ANSI
jdbc.url=jdbc:vdb://denodo_server:9999/some_db
jdbc.username=user
jdbc.password=psswd
jdbc.driver=com.denodo.vdp.jdbc.Driver
default.mapping.include.tables=table1, table2, table3
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(BaseHttpClient.java:538)
at com.complexible.stardog.protocols.http.client.BaseHttpClient.execute(BaseHttpClient.java:364)
at com.complexible.stardog.protocols.http.client.BaseHttpClient.executeHttpPost(BaseHttpClient.java:664)
at com.complexible.stardog.protocols.http.client.BaseHttpClient.executeHttpPost(BaseHttpClient.java:648)
at com.complexible.stardog.protocols.http.client.HttpVirtualGraphAdminConnectionImpl.addOrUpdate(HttpVirtualGraphAdminConnectionImpl.java:155)
at com.complexible.stardog.protocols.http.client.HttpVirtualGraphAdminConnectionImpl.addGraph(HttpVirtualGraphAdminConnectionImpl.java:129)
at com.complexible.stardog.virtual.cli.VirtualGraphAdd.performSecure(VirtualGraphAdd.java:99)
at com.complexible.stardog.cli.admin.SecureStardogAdminCommand.call(SecureStardogAdminCommand.java:61)
at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:55)
at com.complexible.stardog.cli.admin.CLI.main(CLI.java:187)
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.
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?
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$NaturalOrderComparator.compare(Comparators.java:47) ~[?:1.8.0_161]
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:1.8.0_161]
at java.util.TimSort.sort(TimSort.java:220) ~[?:1.8.0_161]
at java.util.Arrays.sort(Arrays.java:1512) ~[?:1.8.0_161]
at java.util.ArrayList.sort(ArrayList.java:1462) ~[?:1.8.0_161]
at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:387) ~[?:1.8.0_161]
at java.util.stream.Sink$ChainedReference.end(Sink.java:258) ~[?:1.8.0_161]
at java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:210) ~[?:1.8.0_161]
at java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161) ~[?:1.8.0_161]
at java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300) ~[?:1.8.0_161]
at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:1.8.0_161]
at com.google.common.base.Joiner.appendTo(Joiner.java:105) ~[guava-26.0-jre.jar:?]
at com.google.common.base.Joiner.appendTo(Joiner.java:152) ~[guava-26.0-jre.jar:?]
at com.google.common.base.Joiner.join(Joiner.java:195) ~[guava-26.0-jre.jar:?]
at com.complexible.stardog.virtual.vega.mapping.MappingGenerator.validateFkRefs(MappingGenerator.java:176) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.mapping.MappingGenerator.generateTriplesMaps(MappingGenerator.java:156) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.generateMappings(RdbmsMappings.java:246) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings(RdbmsMappings.java:112) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings(RdbmsMappings.java:107) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsMappings.parseOrGenerateMappings(RdbmsMappings.java:92) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsVirtualGraphFactory.create(RdbmsVirtualGraphFactory.java:76) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.vega.rdbms.RdbmsVirtualGraphFactory.create(RdbmsVirtualGraphFactory.java:44) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.createVirtualGraph(DefaultVirtualGraphRegistry.java:253) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.createVirtualGraph(DefaultVirtualGraphRegistry.java:239) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.virtual.DefaultVirtualGraphRegistry.add(DefaultVirtualGraphRegistry.java:124) ~[stardog-virtual-core-6.1.1.jar:?]
at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.addVG(VirtualGraphHttpService.java:323) ~[stardog-virtual-protocols-http-server-6.1.1.jar:?]
at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.add(VirtualGraphHttpService.java:109) ~[stardog-virtual-protocols-http-server-6.1.1.jar:?]
at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-6.1.1.jar:?]
at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.2.3.jar:1.2.3]
at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.2.3.jar:1.2.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_161]
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
Manuel,
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.
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?