The aggregated endpoint should allow more flexible constructs for aggregation.
LAPIS has already introduced x.isNull and x.regex to have more powerful filtering constructs. Adding similar functionality to the aggregation logic could offer a lot of additional use-cases.
In the wastewater dashboards, we want to query for combinations of mutations and weeks at the same time. This could be realized by an aggregated query like this, which can translate to one SILO query:
fields=["S[123]","S[124]","S[126]","date.isoWeek"]
table.filter(...).map({pos_123 := S.at(123), pos_124 := S.at(124), pos_126 := S.at(126), week := date.isoWeek()}).groupBy({count:=count()}, {pos_123, pos_124, pos_126, week})
The
aggregatedendpoint should allow more flexible constructs for aggregation.LAPIS has already introduced
x.isNullandx.regexto have more powerful filtering constructs. Adding similar functionality to the aggregation logic could offer a lot of additional use-cases.In the wastewater dashboards, we want to query for combinations of mutations and weeks at the same time. This could be realized by an aggregated query like this, which can translate to one SILO query:
fields=["S[123]","S[124]","S[126]","date.isoWeek"]table.filter(...).map({pos_123 := S.at(123), pos_124 := S.at(124), pos_126 := S.at(126), week := date.isoWeek()}).groupBy({count:=count()}, {pos_123, pos_124, pos_126, week})