-
Type: Improvement
-
Status: Closed
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: V4.0_CSD01
-
Fix Version/s: V4.0_CSD02
-
Component/s: Data Aggregation
-
Labels:None
-
Environment:
[Proposed]
-
Proposal:
-
Resolution:
We had long debates on how to handle the case where a service supported grouping and aggregation on all properties versus having to annotate each property as groupable and/or annotatable.
We initially said that the service would annotate each property as being groupable and/or aggregatable, and the absence of any such annotation, in the presence of an ApplySupported, meant that there were no restrictions on which property could be used in groupby or and aggregate clause. The problem with this was it required looking at all properties to see if any were annotated in order to determine if absence of an annotation on a single property implied it was not groupable/aggregatable, or that there were no such restrictions.
So we added a single property to the ApplySupported aggregation term that a client could check to see if there were any such restrictions. We called this property "AllPropertiesSupported", which is really not very intuitive or meaningful.
There are a couple of options for improving this:
1) We could have two properties, "AllPropertiesGroupable" and "AllPropertiesAggregatable", which would allow us to separately specify whether there are restrictions on grouping versus aggregation.
2) If we don't think there is an interesting scenario for a service having different rules for all properties being groupable versus all properties being aggregatable, we could name the property something like "PropertyRestrictions" which would be true if you can't group/aggregate individual properties, and defaults to false meaning there are no restrictions around properties. This is also kinda nice in that it can have a default value of true, so you can use it as a tag for the case where restrictions exist, or just omit it if restrictions don't exist).