This does not really pertain to TDB directly but rather to the adoption of the RDF 1.1 specifications in Jena 3 which indeed means that data persisted according to RDF 1.0 specifications may not be correctly retrieved when accessed from Jena 3 which follows the RDF 1.1 specifications
See the Jena 3 migration guide - http://jena.apache.org/documentation/migrate_jena2_jena3.html As noted on that page persistent data should be reloaded, you can dump it using the tdbdump tool (preferably using a Jena 2 version) and then reload it with the Jena 3 tools Specifically RDF 1.1 changes handling of typing for some literals (specifically those without a type, a language tag and xsd:string) that causes the issues you see Rob On 10/02/2016 10:22, "Radek Hubner" <[email protected]> wrote: >Hi, > >We are using jena-fuseki 0.2.6 with Jena TDB 2.10 and we would like to >upgrade to new version. I try to test Jena-fuseki 2.3.0 with Jena-TDB >3.0.0 >and I found some incompatibility. When I keep original files with data and >use new Jena-fuseki, sometimes simple query doesn't return any data. After >some debugging I found that problem is in >org.apache.jena.tdb.lib.NodeLib#hash(Hash h, String lex, String lang, >String datatype, NodeType nodeType) and >org.apache.jena.tdb.lib.NodeLib#setHash(Hash h, Node n) >Old version of Jena uses for string nodes dataType " >http://www.w3.org/2001/XMLSchema#string"; but new version sets this as null >and later is replaced by an empty string. This completely changes >calculated hash and Jena-TDB is not able to find node. > >old version string to calculate hash : >e242284a-0fca-4c34-a17a-f8a26935edc1|| >http://www.w3.org/2001/XMLSchema#string|Literal > >new version string to calculate hash : >e242284a-0fca-4c34-a17a-f8a26935edc1|||Literal > >Is this is a bug, or Jena-TDB store is not compatible between versions and >I need to do export and import? > > >Thanks Radek.
