build_args method for the AggregateRequest enforces incorrect order of clauses

[Filipe Oliveira (Personal)]

quoting @stryt2,

Hello,

Under the APPLY {expr} AS {name} section in parameters in detail from the official Redisearch page, it is said that

APPLY ... can be referenced by further APPLY / SORTBY / GROUPBY / REDUCE operations down the pipeline.

However, looking at the current build_args method for the AggregateRequest, the GROUPBY keyword and its fields always come before the APPLY keyword and its fields. E.g.

import redisearch

aggregate_request = redisearch.aggregation.AggregateRequest()
# Call 1
aggregate_request.apply(foo="@bar / 2").group_by("@foo", redisearch.reducers.count())
# or Call 2
# aggregate_request.group_by("@foo", redisearch.reducers.count()).apply(foo="@bar / 2")

print(aggregate_request.build_args())

would have 2 calls (Call 1 and Call 2) both resulting as (irrespective of the order of methods),

['*', 'GROUPBY', '1', '@baz', 'REDUCE', 'COUNT', '0', 'APPLY', '@bar / 2', 'AS', 'foo']

 

However, shouldn't the expected behaviour of Call 1 being

['*', 'APPLY', '@bar / 2', 'AS', 'foo', 'GROUPBY', '1', '@baz', 'REDUCE', 'COUNT', '0']

i.e. the order of the keywords will be dependant upon the order of call?

 

The reason why this is an issue is that Call 2 would result an error (if field foo does not originally exist) saying

No such property foo

whereas Call 1 should not.

 

Any help to get around this issue is greatly appreciated. Thanks.

Originally posted by @stryt2 in #21 (comment)