OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (ODATA-1138) Facilitate processing of aggregated results created with concat


     [ https://issues.oasis-open.org/browse/ODATA-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerald Krause updated ODATA-1138:
---------------------------------

    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?


  was:
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?


       Proposal: 
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> 



  was:
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.



> Facilitate processing of aggregated results created with concat
> ---------------------------------------------------------------
>
>                 Key: ODATA-1138
>                 URL: https://issues.oasis-open.org/browse/ODATA-1138
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: Extension for Data Aggregation, Vocabularies
>    Affects Versions: V4.0_CSD03
>         Environment: Proposed
>            Reporter: Gerald Krause
>             Fix For: V4.0_CSD04
>
>
> 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?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]