You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My issue initiated when trying to perform some json-aggregation through correlated subqueries. I wrote a couple of messages about that to the discord channel.
To track down the problem, I decided to try to write an infix-query, that does the same as the built-in size/count aggregation. The latest scastie that shows that and the initial problem I had, is available at https://scastie.scala-lang.org/tKSoFbB6QBqYqdaHVz7BSg.
However, I further investigated the problem. In the scastie above, I used two nested infix-queries to get the parentheses around correlated subqueries. I think, this should not have been required at all. I.e., instead of having the nested version
should behave the same as the built-in size/count.
However, it doesn't. https://scastie.scala-lang.org/ERJrGZlZRZCPHmumPARr5Q shows that. While size automagically becomes a correlated subquery, mySize doesn't. I think, it's not obvious, that the two queries behave that different, especially given, that they share the same signature.
I think there are two possible solutions to that.
make the infix behave as the aggregation
provide a way to lift an infix into an aggregation
As it was easier for me to implement 2.), I added def aggregate[R](f: T => R): R in trait Query[+T] in phenetic/zio-quill@7b8765d. This allows to rewrite the correlated subquery like this:
This also solves my initial problems (io.getquill.quotation.QuatException: The post-rename field 'xxx' does not exist in an SQL-level type when using joins in more than one correlated subquery).
However, I'm not quite happy with it. Signature probably should be def aggregate[R](f: Query[T] => R): R instead. AggregationOperator.`custom` feels clunky, especially case AggregationOperator.`custom` => stmt"". And I'm wondering, whether the new method is required at all, or the existing .value could do just that?
What do you think?
@getquill/maintainers
The text was updated successfully, but these errors were encountered:
shagoon
changed the title
custom aggregations
custom aggregations in correlated subqueries
Jan 7, 2023
My issue initiated when trying to perform some json-aggregation through correlated subqueries. I wrote a couple of messages about that to the discord channel.
To track down the problem, I decided to try to write an infix-query, that does the same as the built-in size/count aggregation. The latest scastie that shows that and the initial problem I had, is available at https://scastie.scala-lang.org/tKSoFbB6QBqYqdaHVz7BSg.
However, I further investigated the problem. In the scastie above, I used two nested infix-queries to get the parentheses around correlated subqueries. I think, this should not have been required at all. I.e., instead of having the nested version
the plain version
should behave the same as the built-in size/count.
However, it doesn't. https://scastie.scala-lang.org/ERJrGZlZRZCPHmumPARr5Q shows that. While
size
automagically becomes a correlated subquery,mySize
doesn't. I think, it's not obvious, that the two queries behave that different, especially given, that they share the same signature.I think there are two possible solutions to that.
As it was easier for me to implement 2.), I added
def aggregate[R](f: T => R): R
intrait Query[+T]
in phenetic/zio-quill@7b8765d. This allows to rewrite the correlated subquery like this:This also solves my initial problems (io.getquill.quotation.QuatException: The post-rename field 'xxx' does not exist in an SQL-level type when using joins in more than one correlated subquery).
However, I'm not quite happy with it. Signature probably should be
def aggregate[R](f: Query[T] => R): R
instead.AggregationOperator.`custom`
feels clunky, especiallycase AggregationOperator.`custom` => stmt""
. And I'm wondering, whether the new method is required at all, or the existing.value
could do just that?What do you think?
@getquill/maintainers
The text was updated successfully, but these errors were encountered: