Apply Clause

[ViliamVadocz]

I am going to be implementing the apply clause described in the OData Specification.

Related issue: #93

I have some questions and will probably have more as I read more of the code.

1. Can I add to the test data? I expect that the current data there will not have enough features to test aggregate operations.

2. Is there documentation for the internals of this code, preferably some kind of flowchart, that explains the flow of the code from query string to output collection?

3. Has any work been done on the apply clause that I should be aware of before starting?

4. Do you have any special contribution requirements? Is there a formatting specification I should follow?

[BlaiseD]

1. Yes - please include the EF6 tests.
2. No.
3. Not in this repo.
4. Nope - just submit the PR and we'll go from there.

[ViliamVadocz]

Is there a reason for the code repetition in AutoMapper.AspNet.OData.QueryableExtensions methods Get, GetAsync, GetQuery, GetQueryAsync?

I assume this is where I will need to make changes. Currently the code only considers options.Filter, but for apply I will need to look at options.Apply. Is my understanding correct?

[BlaiseD]

I don't see repetition in those methods. Either way your changes should only address new logical changes.

Almost. You'll find multiple properties for ODataQueryOptions already being used:

Where the changes go depends on your research. I'm guessing they would go in the Get* methods with the ODataQueryOptions<TModel> options in the signature applying the new aggregation code to the current results.

[BlaiseD]

SelectExpand's being used not Apply.

[ViliamVadocz]

It looks like Microsoft.AspNet.OData only supports a subset of what is defined in the OData specification.
For example, the specification defines $apply=identity, but there isn't an identity TransformationNode defined.

I will only add tests for what is supported.

[BlaiseD]

Not sure what you mean:

Adding logic for only what's supported sounds about right.

[ViliamVadocz]

I am still scratching my head trying to figure this out.
Why do you apply the operations like $filter using expressions instead of just using ODataQueryOptions.ApplyTo? Is something not supported with ApplyTo or is there some reason related to automatic mapping?

[BlaiseD]

With regard to applying the parsed request, it depends on what you come up with. I would think something like we're doing for OrderBy i.e. create the GroupBy or aggregate expressions based on the parsed data.

[ViliamVadocz]

options.ApplyTo(mapper.ProjectTo<TModel>(query)) doesn't immediately error, but later on gives

Processing of the LINQ expression '(GroupByShaperExpression:
KeySelector: new NoGroupByWrapper(), 
ElementSelector:new OpsTenant{ }
)' by 'InMemoryProjectionBindingExpressionVisitor' failed. This may indicate either a bug or a limitation in EF Core. See https://go.microsoft.com/fwlink/?linkid=2101433 for more detailed information.

This is probably related to the issue you linked.

(trying "/opstenant?$apply=aggregate($count as TenantCount)")

[BlaiseD]

Can't say for sure - that looks like an expression created by/executed in ApplyTo. InMemoryProjectionBindingExpressionVisitor looks it's trying to aggregate on the client and failing. (the link also points to Client vs. Server Evaluation)

In my opinion ApplyTo + ProjectTo + EF makes fixes more difficult.

Building most of the expressions ourselves is more work but makes adjustment easier i.e. you'd have control over what to do about that expression.

[ViliamVadocz]

I have the issue that I don't understand how to build the correct expression and how to use it. I could do something similar to $filter where I use ApplyClause.ApplyTo on an empty queryable and turn that into an expression, but I don't see how to then connect it to the rest of the operations. From what I read, $apply is should be evaluated first and then other things operate on the result of that: http://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/cs02/odata-data-aggregation-ext-v4.0-cs02.html#_Toc435016590
Seems to me like some intermediate type will be required, but I probably just don't understand it well enough yet.

[BlaiseD]

The library references an expression helper which may be helpful.

When the expression type changes you use type of the current expression to build the next one as illustrated in the linked GroupByCall example. I can't say what the solution is without digging in.

It's not always solvable in one day. Consider starting with the parameter expression here. Add a GroupBy to it.

Then map the expression like here and run it.

From there figure out what is or isn't possible using ProjectTo with GroupBy and the aggregate functions - also whether using the existing functions with the new code will be possible. Once you get a couple of snippets working then a solution could become apparent.