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] Created: (ODATA-583) Clarify intentions around implied ordering of input set to aggregation transformations


Clarify intentions around implied ordering of input set to aggregation transformations
--------------------------------------------------------------------------------------

                 Key: ODATA-583
                 URL: http://tools.oasis-open.org/issues/browse/ODATA-583
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Bug
          Components: OData Extension for Data Aggregation 
    Affects Versions: V4.0_CSD01
         Environment: [Proposed]
            Reporter: Michael Pizzo
             Fix For: V4.0_CSD02


The current specification, in several places, refers to the ordering of the input set, and defines rules around preservation of that ordering.

In most cases the input set is not ordered, and preserving the arbitrary order is meaningless and potentially onerous as it may require extra ordering of intermediate results.

This wording is used in operations like topcount which returns the top n values after applying an aggregate (i.e., count) to a field. This preservation of ordering was taken from $top and $skip in [Core], which requires a stable ordering of the results so that, if I do $top=10&$skip=0, followed by $top=10&$skip=10, and both the 10th and 11th orders have the same values for the properties specified in the orderby, I am guaranteed that I consistently get the same values for the 10th versus 11th record.

This same scenario isn't required for methods like topcount, however it may still be desireable to get consistent results when applying methods like topcount to entities that have the same aggregate value. However, rather than imposing a preservation of the order, we can follow the model of $top and $skip by simply saying that the service must guarantee a stable ordering across requests (for example, by adding the key fields to the ordering before applying the top) and not tie the ordering to the order of the input set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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