links
links copied to clipboard
Normalisation bug for `length` in nested query evaluator
(Prerequisite: #888 )
Trying to run:
fun tableLength3() server {
query nested {
length(for (x <-- factorials) [x]) == 3
}
}
results in a normalisation error:
***: Error: "Assert_failure core/query/evalNestedQuery.ml:275:15"
Looking closer, this is in Split.query
, which seems to assume that outer queries must be a comprehension, conditional, concatenation, or singleton.
The "obvious" fix is to add an application case, but I'm not comfortable enough with the shredding algorithm to be confident in the absence of any knock-on effects.
I would leave it for now (or replace the assert failure with a more explicit "length not supported in shredded queries" error) since aggregations such as length
were not considered in the normalization / shredding algorithm in the first place. Extending the theory to cover grouping/aggregation more systematically, and in combination with nested querying, is high on the agenda for the next few months.
Interestingly (at least to me) courtesy of @vcgalpin, some uses of length within nested queries do work:
var db = database "links";
var numbers = table "numbers" with (number: Int) from db;
var test_table = table "test_table" with (
id: Int,
integer: Int)
where id readonly from db;
fun countOcc (i) {
query nested {
length(
for (x <-- test_table)
where (x.integer == i)
[x]
)
}
}
links> countOcc(1);
Query.eval time: 1530
***: Error: "Assert_failure core/query/evalNestedQuery.ml:277:15"
query nested {
for (n <-- numbers)
[(number=n.number,c=countOcc(n.number))]
}