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

Andy Seaborne edited comment on JENA-294 at 8/15/12 6:11 PM:
-------------------------------------------------------------


Your suggestion has something in it but pushing the assign into the RHS will 
need changes in the actual rewrite, not just the pre-condition safeToTransform. 
 It's chaning the shape of the algebra tree in a way the current transformation 
code does not do (function subst calls the Substitution engine) - this will 
need to happen in processFilterWorker.

It may not be necessary, or it may be simpler, after leftjoin to condition as 
the precondition for that rewrite depends on scoping of variables as well.

What we need is comprehensive set of tests.

                
      was (Author: andy.seaborne):
    
You suggestion has something in it but pushing the assign into the RHS will 
need changes in the actual rewrite, not just the pre-condition safeToTransform. 
 It's chaning the shape of the algebra tree in a way the current transformation 
code does not do (function subst calls the Substitution engine) - this will 
need to happen in processFilterWorker.

It may not be necessary, or it may be simpler, after leftjoin to condition as 
the precondition for that rewrite depends on scoping of variables as well.

What we need is comprehensive set of tests.

                  
> 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, 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

        

Reply via email to