-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: V4.0_CSD03
-
Fix Version/s: V4.0_CSD04
-
Component/s: Data Aggregation
-
Labels:None
-
Environment:
Applied
-
Proposal:
For all transformations topXXX and bottomXXX except topcount it has been specified that they do not change the order of the instances in the input set.
| Field | Original Value | New Value |
|---|---|---|
| Issue Type | New Feature [ 2 ] | Bug [ 1 ] |
| Proposal |
Define transformations skip and top:
* The skip transformation takes a non-negative integer n as argument that excludes the first n entities of the input set. It returns all remaining entities in the same order as they occur in the input set. * The top transformation takes a non-negative integer n as argument and returns the first n entities of the input set, if the input set contains more than n entities, otherwise the entire input set. The entities in the result are in the same order as they occur in the input set. Since both transformations operate on the order of entities in the input set, the client needs to know how to specify meaningful requests involving these two transformations. The transformations preceding skip/top in the sequence must first produce a certain order among the entities, and then keep this order stable for the input set of skip/top. Transformations in the first group are the topXXX and bottomXXX transformations, plus the pending orderby transformation ( |
Extend definition of topcount by the statement that it does not change the order of the instances in the input set. |
| Description |
Transformation concat combines entity collections returned by two or more transformation sequences in a new, concatenated collection. For limiting the number of items returned from the overall result collection, today the only way is to use system query options $skip and $top. It is currently not possible to limit the individual result collections of the transformation sequences passed to concat. There are use cases requiring this ability. As an example, consider a request asking for (1) the grand total sales amount along with (2) the sales figures for the first 10 customers. Note that (1) may return a collection with more than one entry in case multiple currencies are involved, hence a global $top does not give full control to the client. In the worst case with more than ten currencies, not a single customer sales amount would be returned. If the aggregated result is put into a stable order with the orderby transformation (described in <issue>), this can be avoided with a top transformation: GET ~/Sales?$apply= concat( groupby( (Currency), Amount with sum as TotalAmount ), groupby( (Customer,Currency), Amount with sum as TotalAmount ) /orderby( Customer,Currency ) /top( 10 ) ) Another example also involving a skip transformation could be a request fetching sales amounts per customer and month in pages of ten data points per request, complemented with minimum and maximum amounts of the entities on this page. The request for the fourth page would look like: GET ~/Sales?$apply= groupby( (Customer,Time/Month,Currency), Amount with sum as TotalAmount ), /orderby( Customer,Time/Month,Currency ) /skip( 30 )/top( 10 ) /concat( identity, aggregate( Amount with min as MinAmount, Amount with max as MaxAmount ) ) |
For all transformations topXXX and bottomXXX except topcount it has been specified that they do not change the order of the instances in the input set. |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| Status | New [ 10000 ] | Open [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Environment | Proposed | Applied |
| Status | Resolved [ 5 ] | Applied [ 10002 ] |
| Status | Applied [ 10002 ] | Closed [ 6 ] |
Resolved as proposed 2018-5-24.