Personally, I don't think I'll be jumping into the Bedrock 4 pool all that soon. I have it on all of my servers, but this morning was my first encounter with using it.
It was not auspicious.
It was a call to }bedrock.cube.viewandsubsets.create, with pLogOutput set to 1.
Yeah, all good, hunky dory, no issues here, nosiree!
Well, aside from the fact that no view was created. And no subsets were created. And no errors were recorded.
Aside from
that, everything worked great, just as reported.
(And yes, I
DID have the pTemp argument set to 0 because regardless of other opinions on the matter I do
NOT, at this point, want views and subsets to be temporary by default.)
So I looked into the actual code for the process.
Oh. My. Fricking. God.
It's not that I can't understand it, it's that I can spend a couple of hours figuring out what it's doing OR I can try to get this last minute work that was thrown at me on a Sunday morning done and out of the way.
But it's not the enhanced complexity of the code that I have an issue with. It's this:
"No more pDebug. When bedrock was first released some 10 years ago the built in logging modes (0 no logging, 1 log actions, 2 log actions which would have been performed but don't do them) was one of the great features of the library. There was no alternative in TurboIntegrator other than to write text files for debugging purposes. But times have changed, with support in TM1's Rest API for debugging and TM1 IDEs like Arc for TM1 supporting step-through debugging there is simply no need for this anymore in the library, hence pDebug is no more."
Mmm. Times have changed. Quite.
You can faff around with the API to do debugging, unless you have some kind of commercial IDE to do it in.
Of course I could write my own REST-based IDE which could do this as well, and have already started dabbling in this, but finishing it by lunch time would seem a tad optimistic.
So the relatively easy way... is log files. Log files which allow you to capture the state of as many or as few variables as you need and see what the values are as the process runs. Log files which will work for non-programmer types who can write TIs but get brain freeze on things like API calls. Log files which will still work into 9.5.2 and 10.2.2.
Which Bedrock 4 does not have. If what it
sees to be an error occurs, it may record it in the server log but when it
fails to see an error, for whatever reason, then you have no idea what happened, or why. You just know that you didn't get the outcome that you were after.
My solution? I called the equivalent Bedrock 3 process instead.
Hey lookie, I got a view. With correctly defined subsets.
Obviously I may need to revisit this if we start doing alternative hierarchies, which obviously aren't supported in Bedrock 3. However if Bedrock 4 fails straight out of the gate with doing something as basic as creating a view, with me needing to dig into the code line by line to figure out why, I'm in no rush to adopt it.