This content has been marked as final. Show 6 replies
Assuming the hierarchy has fixed number of levels before reaching the leaf level departments it is possible to use a new dimension defintion to compute the results without going for a custom aggregator.
Sample soure is available here.
Write to me directly if you need more info at firstname.lastname@example.org
Wow. Very, very nice. Thanks for this example. I do need to support a variable depth hierarchy (basically any well formed tree), so let me see if I can't extend what you've done to support that. I'll ping you if I get stuck.
I do have a couple of questions regarding some of the methods you're using in your Dimension subclass:
1) You're writing to Dimension's "hierarchies" attribute, which the docs say is read-only. Are they incorrect?
2) I couldn't find a Dimension.addAttribute function documented anywhere. Is it protected?
3) I also couldn't find a Hierarchy.createLevel function documented. From you example, it should be public.
Is the documentation missing these, or am I mssing something? Since this package is not open source, we need to rely on the docs.
Thanks again for your help with this.
Oops. Forget about question 1. I see I was looking in the interface, not the class.
The source should get extracted and become available in the FB Pro installed directory once the proper license is entered.
addAttribute is a mx_internal function for now and so is createLevel.
They are mx_internal for now because we didn't want to expose too many APIs leading to confusion.
Oh OK. Getting my hands on the source is even better motivation to moving off the trial than getting rid of that watermark.
Did I naively missed the memory implications of your assumption of an evenly deep organization? Does Hierarchy perform a cross join of the levels in the background? If so, then if I have a user with an uneven tree, with say one deep path and a bunch of shallow paths, then the hierarchy would create a very sparse and memory inefficient cube, right?
If so, then a custom aggregator may be the better solution, since it wouldn't generate sparseness. I'd lose the nice formatting in the row header, but I guess custom compare and display functions could still provide that.
Is this a valid concern?
It would depend on the difference between the shallow and deepnees of the tree. Doing it in custom aggregator may invovled too much data checking and retrieval.