Details

    • Type: Bug
    • Status: In Progress
    • Resolution: Unresolved
    • Affects Version/s: BIGDATA_RELEASE_1_2_2
    • Fix Version/s: None
    • Component/s: Bigdata SAIL
    • Labels:
      None

      Description

      This test case does not give the right results, when there is at least one triple

      SELECT * { 
      
         { SELECT ("3" + 4 as ?X ) 
           {}
         }
         FILTER EXISTS { ?X ?Y ?Z }
      }
      

      It returns the empty result set, the correct answer is a single result with X unbound.
      There are comments in StaticAnalysis.java that suggest that it was written with the belief that the error in the projection causes the projection to be empty rather than ?X to be unbound in the projection.

      Chapter and verse concerning this case are:

      http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#sparqlSelectExpressions

       X := Extend(X, var, expr)
      

      and
      http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#defn_extend

      Extend(?, var, expr) = ? if var not in dom(?) and expr(?) is an error
      

      Judging by the comments in the code, this was implemented at a time when it was believed that the error would result in no solutions, rather than an unbound var.

      I raise this case since I am working on related items 725, 739 and 747

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        The issue here could have a performance impact. We use getDefinitelyBound() to decide when to evaluate FILTERs. If we have to conclude that a SPARQL sub-select is only MAYBE bound for projected variables from computed BINDs() in SELECT projections, then that could cause the FILTER to run at a later stage in the query (assuming that there is another opportunity for the variable to become bound).

        At this time, we should


        - Link the code to this ticket.


        - Mike should take a look at the comment in

        StaticAnalysis.getDefinitelyProducedBindings(final QueryBase queryBase) 
        

        where this ticket would hit case (4) in the internal code documentation.

        I would like to get his assessment on the possibility of a impact before we take further action on this ticket.

        Bryan

        Show
        bryanthompson bryanthompson added a comment - The issue here could have a performance impact. We use getDefinitelyBound() to decide when to evaluate FILTERs. If we have to conclude that a SPARQL sub-select is only MAYBE bound for projected variables from computed BINDs() in SELECT projections, then that could cause the FILTER to run at a later stage in the query (assuming that there is another opportunity for the variable to become bound). At this time, we should - Link the code to this ticket. - Mike should take a look at the comment in StaticAnalysis.getDefinitelyProducedBindings(final QueryBase queryBase) where this ticket would hit case (4) in the internal code documentation. I would like to get his assessment on the possibility of a impact before we take further action on this ticket. Bryan
        Hide
        jeremycarroll jeremycarroll added a comment -

        I have added comments in com.bigdata.rdf.sparql.ast.StaticAnalysis.getDefinitelyProducedBindings(QueryBase)
        in revision r7455

        I suggest that we no-fix for now, but note that Bryan suggests Mike take a look at it: I am reassigning to Mike for now

        Show
        jeremycarroll jeremycarroll added a comment - I have added comments in com.bigdata.rdf.sparql.ast.StaticAnalysis.getDefinitelyProducedBindings(QueryBase) in revision r7455 I suggest that we no-fix for now, but note that Bryan suggests Mike take a look at it: I am reassigning to Mike for now

          People

          • Assignee:
            mikepersonick mikepersonick
            Reporter:
            jeremycarroll jeremycarroll
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: