Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-2043

xsd:integer IV not properly resolved when inlining disabled

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: BLAZEGRAPH_2_1_2
    • Fix Version/s: BLAZEGRAPH_2_2_0
    • Component/s: None
    • Labels:

      Description

      Consider a journal with all inlining disabled and the following query (didn't minimize the query, might be reproducable with simpler queries as well):

      PREFIX :    <http://example/>
      
      SELECT ?a ?y ?d ?z
      {
          ?a :p ?c OPTIONAL { ?a :r ?d }.  
          ?a ?p 1 { ?p a ?y } UNION { ?a ?z ?p } 
      }
      

      The problem is that the integer "1" is not properly resolved, i.e. after the ASTDeferredIVResolutionInitializer has been executed in com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.optimizeQuery() the IV is represented as an XSDIntegerIV(1), without resolved term ID. Tracing it down, I ended up in l. 1208 of ASTDeferredIVResolution:

      iv = ASTDeferredIVResolutionInitializer.decode(label, dte.name());
      

      , which seems to be where the unresolved IV comes from. We need a test case that reproduces the scenario as well as a fix. We also need to make sure that other builtin-datatypes are supported properly.

      Here are the namespace properties that could be used to reproduce the behavior:

      com.bigdata.namespace.asdasdasd.spo.com.bigdata.btree.BTree.branchingFactor=1024
      com.bigdata.rdf.store.AbstractTripleStore.inlineBNodes=false
      com.bigdata.rdf.store.AbstractTripleStore.inlineDateTimes=false
      com.bigdata.rdf.store.AbstractTripleStore.vocabularyClass=com.bigdata.rdf.vocab.NoVocabulary
      com.bigdata.rdf.store.AbstractTripleStore.textIndex=false
      com.bigdata.namespace.asdasdasd.lex.com.bigdata.btree.BTree.branchingFactor=400
      com.bigdata.rdf.store.AbstractTripleStore.axiomsClass=com.bigdata.rdf.axioms.NoAxioms
      com.bigdata.rdf.sail.isolatableIndices=false
      com.bigdata.rdf.store.AbstractTripleStore.justify=false
      com.bigdata.rdf.sail.truthMaintenance=false
      com.bigdata.rdf.store.AbstractTripleStore.blobsThreshold=2147483647
      com.bigdata.rdf.sail.namespace=asdasdasd
      com.bigdata.rdf.store.AbstractTripleStore.quads=false
      com.bigdata.rdf.store.AbstractTripleStore.inlineXSDDatatypeLiterals=false
      com.bigdata.rdf.store.AbstractTripleStore.geoSpatial=false
      com.bigdata.rdf.store.AbstractTripleStore.statementIdentifiers=false
      

      Note1: if we're substituting the integer by a string (i.e., "1" instead of 1, it works as expected)
      Note2: in my scenario the term (i.e., integer 1) is not present in the dictionary, so it should be resolved to a mock IV, but the same problem seems to show up if the term is in the dictionary - both cases should be covered by the test).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              igorkim igorkim
              Reporter:
              michaelschmidt michaelschmidt
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: