Introducing Standard Aggregation Method `union`

[xtofs]

Analogous to existing standard aggregation methods in sections [3.2.1.3 Aggregation Methods] we introduce a union aggregation method that collects (aggregates) the values into a collection with no repeated values and a non-deterministic ordering.

The terminology is derived from the fact that this aggregation is a repeated union operation of representations of mathematical sets.

For example, given a nested collection of primitive types, with a schema like the following.

<EntityType Name="Product">
  <Key>
    <PropertyRef Name="ID"/>
  </Key>
  <Property Name="ID" Type="Edm.Int32" Nullable="false"/>
  <Property Name="Name" Type="Edm.String"/>
  <Property Name="Color" Type="Edm.String"/>
  <Property Name="Tags" Type="Collection(Edm.String)"/>
</EntityType>

and

<EntitySet Name="Products" EntityType="Namespace.Product"/>

The request

GET /service/Products?$apply=aggregate(tags with union as DistinctTags)

will result in :

{
  "@context": "$metadata#Products(DistinctTags)",
  "value": [
    {"DistinctTags": ["Produce", "Groceries", "GiftShop"]}
  ]
}

Analogous to countdistinct:

Instance comparison uses the definition of equality in OData-URL, section 5.1.1.1.1.

Equals operator

[HeikoTheissen]

Since DistinctTags is a dynamic property, does it require the @type control information? You could argue that a collection of strings has a first-class representation in JSON and therefore needs no @type information. But OData-JSON, section 4.6.3 does not mention this case.

[HeikoTheissen]

Since this is a new standard aggregation method, services should be able to declare whether they support it. But the only way to declare that it is not supported is the Aggregation.ApplySupported/AggregatableProperties/SupportedAggregationMethods, which forces the server to enumerate all properties with all supported methods for each property.