This fixes a bug whereby trying to order-by a variable that is bound in the select clause doesn't work.
When we execute a query, we process it in this order:
where/search
group/combine
having/filter
order/arrange
select/format
The problem is that the aggregate vars only appear in the select clause, but by the time we add that binding to the solution, the solutions are already sorted - the binding just isn't available to sort by.
Fortunately, we already had all the necessary code written, I just needed to rearrange it. select/format first filters out any SolutionModifier Selectors, and then applies them in a transducer, which is then piped into the formatting pipeline.
All I had to do was factor out the modification xformer into a new function and then call that before order/arrange. So now it looks like this:
This fixes a bug whereby trying to
order-bya variable that is bound in the select clause doesn't work.When we execute a query, we process it in this order:
where/searchgroup/combinehaving/filterorder/arrangeselect/formatThe problem is that the aggregate vars only appear in the select clause, but by the time we add that binding to the solution, the solutions are already sorted - the binding just isn't available to sort by.
Fortunately, we already had all the necessary code written, I just needed to rearrange it.
select/formatfirst filters out anySolutionModifierSelectors, and then applies them in a transducer, which is then piped into the formatting pipeline.All I had to do was factor out the modification xformer into a new function and then call that before order/arrange. So now it looks like this:
where/searchgroup/combinehaving/filterselect/modifyorder/arrangeselect/format