-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-expand transformation #293
base: main
Are you sure you want to change the base?
Conversation
vocabularies/Analytics.json
Outdated
"@Core.OptionalParameter": { "DefaultValue": "false" } | ||
} | ||
], | ||
"$ReturnType": { "$Collection": true, "$Type": "Edm.EntityType" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the EntityType is not enough. We will need some of the information that we also get from a hierarchical query. Most importantly, the LimitedDescendantCount but also the DrillState and the DistanceFromRoot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we need an instance annotation whose type contains a subset of the properties of Hierarchy.RecursiveHierarchyType
. Which subset exactly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ThomasChadzelek I had found the LimitedDescendantCount, the DrillState and the DistanceFromRoot. Is that it? Or already too much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it sufficient if these instance annotations are returned by the auto-expand function? If one node is expanded, they must be computed by the OData model itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think yes. In the other cases, the model is creating requests to manually expand the visual groups. The backend would not even be aware that we are creating a visual grouping on the screen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ThomasChadzelek I had found the LimitedDescendantCount, the DrillState and the DistanceFromRoot. Is that it? Or already too much?
What about LimitedRank? Our new favorite ;-)
DistanceFromRoot might be redundant because the hierarchy is leveled, not recursive?
It is needed if `AggregatedValuesLeafFilter` is specified or properties from `Aggregation` occur in `SiblingOrder`. Especially the latter is typical.
vocabularies/Analytics.xml
Outdated
<Annotation Term="Core.Description" String="Sort specification to apply to all direct descendants of a given entry in the resulting leveled hierarchy" /> | ||
</Parameter> | ||
<Parameter Name="BeforeAggregationFilter" Type="Edm.String" Nullable="false"> | ||
<Annotation Term="Core.Description" String="Expression valid for `filter` transformation to restrict the input set before any further procressing" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you achieve the same thing with a filter() transformation beforehand, in the same $apply? For TopLevels, we do likewise with orderby() or search() or filter().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but then the backend would have to take all these transformations together and process them as one "auto-expand" transformation. (At least with the Analytical Engine, the filter is part of the auto-expand operation.)
If the backend agrees, we can change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the backend disagrees, do we need support for search as well? Or is that too fuzzy for analytics?
Open issue: Whether and how to instruct the transformation to create one row for an expanded group header above its descendants and another row for the subtotals below its descendants. |
vocabularies/Analytics.json
Outdated
"$IsBound": true, | ||
"@Common.Experimental": true, | ||
"@Core.Description": "`$apply` transformation that expands an unnamed leveled hierarchy with custom aggregation of certain properties", | ||
"@Core.LongDescription": "Example transformation sequence:\n```\n$apply=filter(Industry eq 'IT')\n/groupby((Country,CountryName,Region,RegionName),\n filter($these/aggregate(Amount) gt 0 and\n $these/aggregate(Currency) ne null))\n/concat(\n Analytics.AutoExpand(\n Levels=[{\"P\":[\"Country\",\"CountryName\"]},\n {\"P\":[\"Region\",\"RegionName\"]}],\n LeafLevel=[\"Segment\",\"Industry\"],\n Aggregation=[\"Amount\",\"Currency\"],\n SiblingOrder=[{\"Property\":\"Amount\",\n \"Order\":\"desc\"}],\n ExpandLevels=[{\"Entry\":[\"US\",\"USA\"],\"Levels\":0},\n {\"Entry\":[\"DE\",\"Germany\",\"BW\",\"Baden-Württemberg\"],\"Levels\":2}])\n /concat(aggregate($count) as ResultEntriesCount,\n skip(20)/top(10)),\n aggregate(Amount,Currency))\n```\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In UI5 we start with the leaves count that is missing in the example. It would be a term groupby((Country,CountryName,Region,RegionName))/aggregate($count as LeavesCount)
in the outer concat followed by the grand total term aggregate(Amount,Currency)
that is currently last in the example. The third term in the outer concat would be Analytics.AutoExpand(...)/concat(aggregate($count) as ResultEntriesCount,skip(20)/top(10))
.
vocabularies/Analytics.json
Outdated
{ | ||
"$Name": "LeafLevel", | ||
"$Collection": true, | ||
"@Core.Description": "A possibly empty set of property names that constitute, together with the property names from `Levels`, the leaf level of the leveled hierarchy", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A possibly empty set of property names
I wonder how that would work. If LeafLevel
is empty then the last level in Levels
is not expanded, cannot be expanded and could as well be written into LeafLevel
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't LeafLevel
simply the last entry in Levels
, then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There can be several properties used for grouping on the leaf level that are not used for visual grouping / group headers.
The interesting part is that we have three things:
- properties used for visual grouping
- properties used additionally for grouping on the leaf level
- the number of visual groups initially expanded.
I think we had decided somewhen in the past that 3. is not necessary for the AutoExpand function as one can simply as collapsed visual groups to 2. But I wonder whether that decision is still good when introducing ExpandLevels. Should the backend then not know which visual groups are introduced, how grouping is done on leaf level and how deep to expand initially?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The leaf level is just the deepest grouping level, therefore we only need the parameter Levels
, not LeafLevel
.
In the current definition, nodes not mentioned in ExpandLevels
are completely expanded. If you want the default to be "expand N levels", we need an additional parameter for that N.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can do it like that. But the question is how to denote the leaf level. Is it always the last of the Levels? And hence this last level is not and cannot be expanded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be stated explicitly in the Levels description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at the FE examples, then on the leaf level there are individual (unaggregated) records. If that is the target state, one could also argue that the last level can still be expanded and below this last level are the unaggregated records.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
odata-vocabularies/vocabularies/Analytics.xml
Line 224 in 8c7b80b
entries on the finest-grained level cannot be expanded further. |
See wiki.