No action as this can be solved by the client e.g. using compute():
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(1 as concat_index),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(2 as concat_index))
No action as this can be solved by the client e.g. using compute():
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(1 as concat_index),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(2 as concat_index))
Description
The concat transformation creates a potentially heterogeneous result set consisting of entities with different structures.
The result is a contiguous list of entities without explicit boundaries to separate the result entities created by one concat parameter from the next. In case an OData client needs to know the concat parameter to which a result entity is related, it has to evaluate the result entities with the same or similar logic expressed in the request a second time.
Example:
Using the example model from the Data Aggregation extension, consider a request to retrieve sales amounts grouped by customer for two different subsets of sales entities qualified by complex filter expressions:
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total)),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total)))
Which is the last entity in the result collection that matches complex expression 1?
Repeating the logic on client side can be avoided, if the server adds information about the related concat parameter to every entity in the result of a transformation sequence passed to concat.
For this purpose, this new term could be annotated to these entities:
<Term Name=“RelatedConcatParameter“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Position of the transformation sequence in the list of concat parameters, whose result contans this entity. Position counting starts at 0" />
</Term>
A server should (must) add this annotation, if concat is the last transformation in the sequence passed to $apply, i.e. concat is not nested inside another transformation or followed by another transformation.
Several options seem to exist:
Option A
Repeating the logic on client side can be avoided, if the server adds information about the related concat parameter to every entity in the result of a transformation sequence passed to concat.
For this purpose, this new term could be annotated to these entities:
<Term Name=“RelatedConcatParameter“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Position of the transformation sequence in the list of concat parameters, whose result contans this entity. Position counting starts at 0" />
</Term>
A server should (must) add this annotation, if concat is the last transformation in the sequence passed to $apply, i.e. concat is not nested inside another transformation or followed by another transformation.
Option B
The number of annotations required in the response payload could be reduced by annotating only the entities at the boundary of the next partial result, using this term:
<Term Name=“ResultOfContextArgument“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Index number of the argument provided to the concat transformation whose result contains this and subsequent entities. The first argument has index 0." />
</Term>
Description
The concat transformation creates a potentially heterogeneous result set consisting of entities with different structures.
The result is a contiguous list of entities without explicit boundaries to separate the result entities created by one concat parameter from the next. In case an OData client needs to know the concat parameter to which a result entity is related, it has to evaluate the result entities with the same or similar logic expressed in the request a second time.
Example:
Using the example from the Data Aggregation extension, consider a request to retrieve sales amounts grouped by customer for two different subsets of sales entities qualified by complex filter expressions:
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total)),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total)))
Which is the last entity in the result collection that matches complex expression 1?
The concat transformation creates a potentially heterogeneous result set consisting of entities with different structures.
The result is a contiguous list of entities without explicit boundaries to separate the result entities created by one concat parameter from the next. In case an OData client needs to know the concat parameter to which a result entity is related, it has to evaluate the result entities with the same or similar logic expressed in the request a second time.
Example:
Using the example model from the Data Aggregation extension, consider a request to retrieve sales amounts grouped by customer for two different subsets of sales entities qualified by complex filter expressions:
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total)),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total)))
Which is the last entity in the result collection that matches complex expression 1?
Option A
Repeating the logic on client side can be avoided, if the server adds information about the related concat parameter to every entity in the result of a transformation sequence passed to concat.
For this purpose, this new term could be annotated to these entities:
<Term Name=“RelatedConcatParameter“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Position of the transformation sequence in the list of concat parameters, whose result contans this entity. Position counting starts at 0" />
</Term>
A server should (must) add this annotation, if concat is the last transformation in the sequence passed to $apply, i.e. concat is not nested inside another transformation or followed by another transformation.
Option B
The number of annotations required in the response payload could be reduced by annotating only the entities at the boundary of the next partial result, using this term:
<Term Name=“ResultOfContextArgument“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Index number of the argument provided to the concat transformation whose result contains this and subsequent entities. The first argument has index 0." />
</Term>
Several options seem to exist:
Option A
Repeating the logic on client side can be avoided, if the server adds information about the related concat parameter to every entity in the result of a transformation sequence passed to concat.
For this purpose, this new term could be annotated to these entities:
<Term Name=“RelatedConcatParameter“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Position of the transformation sequence in the list of concat parameters, whose result contans this entity. Position counting starts at 0" />
</Term>
A server should (must) add this annotation, if concat is the last transformation in the sequence passed to $apply, i.e. concat is not nested inside another transformation or followed by another transformation.
Option B
The number of annotations required in the response payload could be reduced by annotating only the entities at the boundary of the next partial result, using this term:
<Term Name=“ResultOfConcatArgument“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Index number of the argument provided to the concat transformation whose result contains this and subsequent entities. The first argument has index 0." />
</Term>
Option A
Repeating the logic on client side can be avoided, if the server adds information about the related concat parameter to every entity in the result of a transformation sequence passed to concat.
For this purpose, this new term could be annotated to these entities:
<Term Name=“RelatedConcatParameter“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Position of the transformation sequence in the list of concat parameters, whose result contans this entity. Position counting starts at 0" />
</Term>
A server should (must) add this annotation, if concat is the last transformation in the sequence passed to $apply, i.e. concat is not nested inside another transformation or followed by another transformation.
Option B
The number of annotations required in the response payload could be reduced by annotating only the entities at the boundary of the next partial result, using this term:
<Term Name=“ResultOfConcatArgument“ Type=“Edm.Int16“>
<Annotation Term="Core.Description" String="Index number of the argument provided to the concat transformation whose result contains this and subsequent entities. The first argument has index 0." />
</Term>
No action as this can be solved by the client e.g. using compute():
GET ~/Sales?$apply=concat(
filter(<complex expression 1>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(1 as concat_index),
filter(<complex expression 2>)/groupby((Customer),aggregate(Amount with sum as Total))/compute(2 as concat_index))
New Feature
Major