MultiLevelExpand transformation

[HeikoTheissen]

See wiki.

[uhlmannm]

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.

[HeikoTheissen]

So we need an instance annotation whose type contains a subset of the properties of Hierarchy.RecursiveHierarchyType. Which subset exactly?

[uhlmannm]

@ThomasChadzelek I had found the LimitedDescendantCount, the DrillState and the DistanceFromRoot. Is that it? Or already too much?

[HeikoTheissen]

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.

[uhlmannm]

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.

[ThomasChadzelek]

@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?

[ThomasChadzelek]

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().

[HeikoTheissen]

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.

[ThomasChadzelek]

If the backend disagrees, do we need support for search as well? Or is that too fuzzy for analytics?

[HeikoTheissen]

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.

[uhlmannm]

Whether to duplicate the group headers so that they are included before and after their descendants

[ralfhandl]

Why "auto" if it is part of the request? The annotation of the same name tells what the server will do without needing input from the client.

[HeikoTheissen]

Why "auto" if it is part of the request? The annotation of the same name tells what the server will do without needing input from the client.

"Automated expansion" as opposed to "interactive expansion" where the user must click the expand button on every group header.

[ralfhandl]

OData is not about user interaction with a UI, it is about interaction of the UI/client with the server, so "auto" feels wrong here, especially because the word "AutoExpand" has a different meaning in the Core vocabulary.

[uhlmannm]

@ralfhandl Ok. So maybe the name is not good. It comes from the internal name for the OData V2 feature to enable the automatic expansion of several levels. What would be a better name? What we get back is a slice (defined by top and skip) of a partially expanded hierarchy. The hierarchy itself is defined by the group levels provided by the client. And in the hierarchy data aggregation may have to be done, also as defined by the client.
For recursive hierarchies we called the function TopLevels. But I do not see how that could be of help here.
What about DataAggregationHierarchy?

[ralfhandl]

"D" and "A" are unusually short names. Why not "DimensionProperties" and "AdditionalDimensionProperties"?