There's currently a limitation on for each quantifiers with null-on-empty, which is that they are only implemented when they sit below a select expression. If a quantifier is directly placed somewhere, then we can end up dropping the null-on-empty behavior, as demonstrated in this test:
|
void testPlanQueryOnRestNoWithNullOnEmpty() { |
|
CascadesPlanner cascadesPlanner = setUp(); |
|
final var plan = planGraph( |
|
() -> { |
|
var qun = fullTypeScan(cascadesPlanner.getRecordMetaData(), "RestaurantRecord"); |
|
|
|
qun = forEachWithNullOnEmpty(selectWithPredicates(qun, |
|
ImmutableList.of("rest_no", "name"), |
|
fieldPredicate(qun, "rest_no", new Comparisons.SimpleComparison(Comparisons.Type.GREATER_THAN, 1_000_000L)) |
|
)); |
|
return Reference.initialOf(LogicalSortExpression.unsorted(qun)); |
|
}); |
|
|
|
// Note: this is a bug as the "null on empty" part of the quantifier is dropped |
|
assertMatchesExactly(plan, |
|
mapPlan( |
|
typeFilterPlan( |
|
scanPlan() |
|
.where(scanComparisons(range("([1000000],>"))))) |
|
.where(mapResult(recordConstructorValue(exactly(fieldValueWithFieldNames("rest_no"), fieldValueWithFieldNames("name")))))); |
|
|
|
try (FDBRecordContext context = openContext()) { |
|
openNestedRecordStore(context); |
|
|
|
// Note: this should return a single null value rather than an empty list |
|
try (RecordCursor<QueryResult> cursor = executeCascades(recordStore, plan)) { |
|
List<QueryResult> results = cursor.asList().join(); |
|
assertThat(results, Matchers.empty()); |
|
} |
|
} |
|
} |
Note the "bug" mentioned here where the null-on-emptiness is dropped. This gets worse with #3426, where we now get type errors as we try and mix nullable and non-nullable types in the same reference, a direct consequence of the the non-handling of this quantifier type in graphs like this.
There are probably two work items here. The first is to ban these kinds of expressions in query graphs. The second is to make it so that we can handle them correctly.
There's currently a limitation on for each quantifiers with null-on-empty, which is that they are only implemented when they sit below a select expression. If a quantifier is directly placed somewhere, then we can end up dropping the null-on-empty behavior, as demonstrated in this test:
fdb-record-layer/fdb-record-layer-core/src/test/java/com/apple/foundationdb/record/provider/foundationdb/query/FDBSimpleQueryGraphTest.java
Lines 220 to 250 in 29cfcd0
Note the "bug" mentioned here where the null-on-emptiness is dropped. This gets worse with #3426, where we now get type errors as we try and mix nullable and non-nullable types in the same reference, a direct consequence of the the non-handling of this quantifier type in graphs like this.
There are probably two work items here. The first is to ban these kinds of expressions in query graphs. The second is to make it so that we can handle them correctly.