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

ClassCastException when binding non-uri values to a variable that occurs in predicate position.

    Details

      Description

      With the following query:

      SELECT * WHERE { ?s ?p ?o }

      When providing a BindingSet with a literal value bound to variable ?p, the evaluate methods fails with a ClassCastException.

      Imho the query should just return no results. It should not fail, and definitely not with a ClassCastException.

      To solve, line 248 in ASTSerachOptimizer should probably have an instance-check added, e.g.:

      if (p.isConstant() && p.getValue() instanceof URI) {
      

      Exception that is now thrown with the attached testcase:

      java.lang.ClassCastException: com.bigdata.rdf.model.BigdataLiteralImpl cannot be cast to org.openrdf.model.URI
      	at com.bigdata.rdf.sparql.ast.eval.ASTSearchOptimizer.extractSearches(ASTSearchOptimizer.java:250)
      	at com.bigdata.rdf.sparql.ast.eval.ASTSearchOptimizer.optimize(ASTSearchOptimizer.java:151)
      	at com.bigdata.rdf.sparql.ast.optimizers.ASTOptimizerList.optimize(ASTOptimizerList.java:92)
      	at com.bigdata.rdf.sparql.ast.eval.AST2BOpUtility.convert(AST2BOpUtility.java:207)
      	at com.bigdata.rdf.sparql.ast.eval.ASTEvalHelper.evaluateTupleQuery(ASTEvalHelper.java:228)
      	at com.bigdata.rdf.sail.BigdataSailTupleQuery.evaluate(BigdataSailTupleQuery.java:98)
      	at com.bigdata.rdf.sail.BigdataSailTupleQuery.evaluate(BigdataSailTupleQuery.java:80)
      	at com.bigdata.rdf.sail.TestBindLiteralUri.executeQuery(TestBindLiteralUri.java:71)
      	at com.bigdata.rdf.sail.TestBindLiteralUri.testBindLiteralToPredicateUri(TestBindLiteralUri.java:55)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at junit.framework.TestCase.runTest(TestCase.java:154)
      	at junit.framework.TestCase.runBare(TestCase.java:127)
      	at junit.framework.TestResult$1.protect(TestResult.java:106)
      	at junit.framework.TestResult.runProtected(TestResult.java:124)
      	at junit.framework.TestResult.run(TestResult.java:109)
      	at junit.framework.TestCase.run(TestCase.java:118)
      	at junit.framework.TestSuite.runTest(TestSuite.java:208)
      	at junit.framework.TestSuite.run(TestSuite.java:203)
      	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
      	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
      
      
      

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        In general, we do not provide in-depth validation of the query before execution and there is very little attempt to give errors such as this one a nice error message. Instead, we tend to validate during execution. We can make spot fixes such as this, but the issue is pervasive.

        Show
        bryanthompson bryanthompson added a comment - In general, we do not provide in-depth validation of the query before execution and there is very little attempt to give errors such as this one a nice error message. Instead, we tend to validate during execution. We can make spot fixes such as this, but the issue is pervasive.
        Hide
        gjdev gjdev added a comment -

        The suggested fix solves it, and doesn't need an error message at all.

        The fix aligns the Bigdata behavior with the behavior of the OpenRdf stores for the same query+bindings, which imho is a good thing.

        It's a minor issue, agreed. It actually seems that Bigdata usually does the right thing when queries have bound values at unmatchable positions.

        Show
        gjdev gjdev added a comment - The suggested fix solves it, and doesn't need an error message at all. The fix aligns the Bigdata behavior with the behavior of the OpenRdf stores for the same query+bindings, which imho is a good thing. It's a minor issue, agreed. It actually seems that Bigdata usually does the right thing when queries have bound values at unmatchable positions.
        Hide
        bryanthompson bryanthompson added a comment -

        Applied fix as documented above.

        Committed revision r6815.

        Show
        bryanthompson bryanthompson added a comment - Applied fix as documented above. Committed revision r6815.

          People

          • Assignee:
            bryanthompson bryanthompson
            Reporter:
            gjdev gjdev
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: