Try to order by function

[kuba--]

Signed-off-by: kuba-- kuba@sourced.tech

Fixes #691

Is there any better place to resolve this functions/expressions for order by?
So far I resolve order by with literals which exist in schema.

[erizocosmico]

can you rewrite this as SELECT fi, COUNT(*) FROM ( to see if it still works?
COUNT in orderby receives a row in Eval (which should be the buffer) and since the first item is the result of the count, it will work. But it won't if you change the order.

[erizocosmico]

Same as previous comment

[kuba--]

OK. I've added more tests ...

[kuba--]

...and it still works

[erizocosmico]

Can you add the following test case?

SELECT s FROM mytable GROUP BY s ORDER BY COUNT(*)

[kuba--]

This one of course doesn't work because we don't have COUNT in projection so we'll get:
OrderBy does not support aggregation expressions
The same as you do:

SELECT s, 1 + COUNT(*) FROM mytable GROUP BY s ORDER BY COUNT(*) + 1

or

SELECT s, COUNT(*) as cnt FROM mytable GROUP BY s ORDER BY COUNT(*)

[erizocosmico]

But that one should work. Order by should to the same as having does and push down expressions to the group by if needed. Rebase against the HAVING branch, so you can test this correctly because you will come across this issue: When HAVING pushes down, it creates a Project node on top of it. You will need to either project that as well and create another project on top of order by or move that project before the order by node.

Basically:

SELECT i FROM mytable GROUP BY i HAVING COUNT(*) > 0 ORDER BY SUM(i)

Will generate:

OrderBy(SUM(i))
|- Project(i)
 |- Having(`count(*)` > 0)
  |- GroupBy(i, count(*))
    |- Table(i)

And your rule should convert this to:

Project(i)
|- OrderBy(`sum(i)`)
 |- Having(`count(*)` > 0)
  |- GroupBy(i, count(*), sum(i))
    |- Table(i)

Perhaps instead of looking for a Project with a Having child a better, and more general, solution would be to change resolve_having rule to not wrap Having node with a project, but the whole node if the schema changed from the initial node.

[kuba--]

@erizocosmico Would be great if we can generalize some rules (especially for group/orderBy), but I think it will require a little bit more refactoring and I'm afraid of destabilization.
So far, this little trick solved the problem.

One important thing regarding tests - I also changed how do we compare results!
Currently in testQueryWithContext we call require.ElementsMatch(expected, rows) because for query results ordering can be random (doesn't matter). But it's not the case for ORDER BY queries. For ORDER BY we must call require.Equal.
Current workaround just checks if query string contains ORDER BY.
In other words, so far all ORDER BY queries pass, does not matter what order was returned and what was expected.