Hi Paul,
For as long as I remember an element would remain to be a 'consolidated' (by type) element even if one removed all components. Have to admit that I'm drawing a blanc on the fact if one could then associate data with such element or not, you seem to suggest in your initial message that one could.
With multiple (alternate) hierarchies this distinction between leaves and consolidations becomes a tad more important as leaves are shared across all hierarchies, albeit that they don't need to be referenced in all hierarchies, whereas consolidated elements are unique to a hierarchy. As such consolidated element names have to be unique among all consolidated elements of that hierarchy and all leaves whereas a name of for a leaf element can't exist as a consolidated element in any of the hierarchies.
Personally I'm in favour of retaining the behaviour of keeping the element as a consolidation (albeit that I think, as long as the uniqueness rules apply the REST API allows changing the type if an element doesn't have children any longer) and that therefore the PA modeller behaviour is kind of expected (read: you'd have to delete it and add it, as a leaf, again).
What worries me, and what I'd be treating as an issue, is if the behaviour between different hierarchies would be different. The 'same-named' hierarchy is nothing more and nothing less than yet another, alternate, hierarchy whose name happens to be the same as the dimension. The only time that this has any special meaning is when 'old', read: hierarchy oblivious, clients come in and this would be the hierarchy that is used to represent that dimension. Within the server and therefore it's REST API there is absolutely no special treatment of that hierarchy and as such there shouldn't be any difference in behaviour in this case either.
------------------------------
Hubert Heijkers
------------------------------
Original Message:
Sent: Wed November 06, 2019 05:54 PM
From: Paul Simon
Subject: Leaves Hierarchy does not contain all base level elements
Hi Stuart
I would be a little less concerned if this was only a problem in Architect since I know that Architect is sadly on its way out. However, this consolidation almost certainly end up without any children and was therefore converted to a leaf level element due to updates carried out by TI and that will probably be around a lot longer than Architect.
As you point out, at present there is an anomaly because from what I have seen childless consolidations only get converted to N levels in the Main Hierarchy and not in Named Hierarchies where they stay as consolidations.
I think that IBM might need to take a decision. I personally would be happy if Architect and TI were amended so that a childless consolidation stayed as a consolidation and did not get changed into a simple/leaf/base/N type just because it no longer had any children. However, other users of the product may rely on this being the way that the product works. Perhaps one option would be to add a TM1S.CFG parameter defaulted to the current legacy behaviour but with the option to convert to consolidations staying as consolidations.
One issue in subsets is that the standard way to get base level elements is to use an MDX expression with TM1FilterByLevel for Level 0. However, this will always include Consolidations with no children since in Level terms they are at level 0. However, in practice when most developers want level 0 what they really mean is N level. It would be useful if there was a special TM1 specific MDX function eg TM1FilterByType (Equivalent to DTYPE or the more modern hierarchy specific EntityType) so that you could explicitly filter for N type elements.
Regards
Paul Simon
------------------------------
Paul Simon
Original Message:
Sent: Wed November 06, 2019 06:54 AM
From: STUART KING
Subject: Leaves Hierarchy does not contain all base level elements
I can reproduce this by adding an element to a hierarchy (with the same name as the parent dimension) as the consolidated type, and then changing it using Architect back to the leaf type. I'll discuss with our development team and get back to you. Seems like a defect...however, I've noticed that Workspace modeling does not allow you to change an element from consolidated to leaf. The ability to change an element from a consolidation to a leaf seems to only exist in Architect (didn't test Performance Modeler yet). I'm wondering if this isn't implemented in the REST API for a reason.
------------------------------
Stuart King
IBM Planning Analytics Offering Manager
Original Message:
Sent: Tue November 05, 2019 01:11 PM
From: Paul Simon
Subject: Leaves Hierarchy does not contain all base level elements
Hi
I maybe wrong but my understanding is that once you implement Named Hierarchies on a dimension then the Leaves hierarchy should automatically include any base level element in the dimension. However, I have a case where I have a base level element in the main hierarchy (the one where the hierarchy name is the same as the dimension name), that does not appear in the Leaves hierarchy.
I suspect that this may be because the element was originally a consolidation. In the main hierarchy, if you delete all elements below a consolidation, then it is changed into a base level 'simple type' element. I would guess that behind the scenes the element is being deleted as a consolidation and re-inserted as a base level element. However, its arrival as a base level element is not being picked up and therefore it does not appear in the Leaves hierarchy.
I have tried a few experiments such as entering data against the former consolidation that is now a base level element and then run a save data, however, the element still does not appear in the Leaves hierarchy.
I have tried to raise a PMR for that but the system for that does not appear to be working for me.
Regards
Paul Simon
------------------------------
Paul Simon
------------------------------
#PlanningAnalyticswithWatson