[jira] [Comment Edited] (JENA-294) TransformFilterEquality does not handle starting OPTIONAL well

["Andy Seaborne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434106#comment-13434106 ] 

Andy Seaborne edited comment on JENA-294 at 8/15/12 12:23 AM:
--------------------------------------------------------------

Example:

data:

@prefix : <http://example/> .
:s :q 123 .

query:

PREFIX : <http://example/>

SELECT * 
{
  OPTIONAL { ?x :p ?z }
  FILTER(?z = :a)
}

result:

No rows : The OPTIONAL does not match, so the result to that point is one row, not bindings.  The FILTER fails, ?z is not bound.  Hence result is no rows.

With the patch (the change around line 132 is the critical point):

One row, ?z bound to :a caused by assign to the empty row.

Checking, then pushing the assign inside the optional right-hand side should address this making the assignment happen if and only if the optional clause matches.

                
      was (Author: andy.seaborne):
    Example:

data:

@prefix : <http://example/> .
:s :q 123 .

query:

PREFIX : <http://example/>

SELECT * 
{
  OPTIONAL { ?x :p ?z }
  FILTER(?z = :a)
}

result:

No rows : The OPTIONAL does not match, so the result to that point is one row, not bindings.  The FILTER fails, ?z is not bound.  Hence result is no rows.

With the patch (the change around line 132 is the critical point):

One row, ?z bound to :a caused by assign to the empty row.

                  
> TransformFilterEquality does not handle starting OPTIONAL well
> --------------------------------------------------------------
>
>                 Key: JENA-294
>                 URL: https://issues.apache.org/jira/browse/JENA-294
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: ARQ
>    Affects Versions: Jena 2.7.4
>            Reporter: Simon Helsen
>         Attachments: patch.txt
>
>
> There was one other case where our tests were stuck on a very slow query execution because transformFilterEquality failed to optimize. The problem is that the optimizer gives up whenever the WHERE clause starts with an OPTIONAL clause. The reason is that the generated algebraic formula starts with a TableUnit and this is not handled correctly. 
> I have attached a patch which fixes the problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira