afs commented on code in PR #1631:
URL: https://github.com/apache/jena/pull/1631#discussion_r1029650336
##########
jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/TransformFilterImplicitJoin.java:
##########
@@ -120,10 +120,14 @@ private static Op apply(ExprList exprs, Op subOp) {
// ---- Check if the subOp is the right shape to transform.
Op op = subOp;
- // Special case : deduce that the filter will always "eval unbound"
- // hence eliminate all rows. Return the empty table.
+ // LATERAL : This is not longer true.
+// // Special case : deduce that the filter will always "eval unbound"
+// // hence eliminate all rows. Return the empty table.
+// if (testSpecialCaseUnused(subOp, joins, remaining))
+// return OpTable.empty();
+ // But simply skipping this causes (filter) to become (assign) which
fails as (assign) does not handle errors.
if (testSpecialCaseUnused(subOp, joins, remaining))
- return OpTable.empty();
+ return null;
Review Comment:
That's a possibility - I think it seems to designing for handling a bad
query case (if not LATERAL), rather than optimization in LATERAL.
It does seem to be a risk more widely, now and in future changes and not
just in LATERAL - e.g. optimizing then substituting (e.g. parameterized
queries). (NOT)EXISTS as well which is related to substitution. The fix for
JENA-500 is a specific fix for the whole-query case.
The transform walk is bottom up so it will run over the code - the walker
needs to be changed to avoid certain ops.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
