TM1 Forum

Admin note: This has been separated from this topic.

Sorry for my problem raised here, it seems it is a 'common sense' for developers out there but I just learn and would like to share.

After spending some time checking the prolog, there are defined 'cVeiwSource' and 'cViewTarget'
I was simply ignoring the 'cViewTarget' as I did not know its purpose in the code.

At the end of the Prolog there is a Bedrock.Cube.Data.Clear, I wonder what it is used for then I googled it
According to this page,

If no view (pView) or filter (pFilter) is specified, the entire cube(s) will be cleared out.

So I added the pfilter to include dim Account and it works fine now, the figures in other dimension remains, and my intended figures with that Account are transferred from other scenario.

But I got a question, does the pfilter means in Bedrock.Cube.Data.Clear, will clear that particular filtered dimension, and write back data from 'Data' tab? And also preserve other intersections not specific in that pfilter? Thanks a lot again

creahui wrote: ↑Fri Aug 28, 2020 6:49 am

If no view (pView) or filter (pFilter) is specified, the entire cube(s) will be cleared out.

But I got a question, does the pfilter means in Bedrock.Cube.Data.Clear, will clear that particular filtered dimension, and write back data from 'Data' tab? And also preserve other intersections not specific in that pfilter? Thanks a lot again

I have to start with a disclaimer that I'm moving away from using Bedrock. First, it's failed on me too many times, usually when I've needed it most (to get something done quickly), and second now that it's a GitHub project... well, that's good and it's bad. It's theoretically good in the sense that it allows more public contributions to it. It's practically bad in that if there are constant updates to Bedrock, as opposed to the old method of "This is version x", then your code isn't so much built on rock as on shifting sands. (Also GitHub is fine for programmers, but most TM1 admins wouldn't necessarily be programmers in the practical sense. Of those that are, not everyone works collaboratively and uses and/or needs a tool like GitHub. It's easy enough to pull down an archive from there but if you want to contribute to it there's a bunch of new Git skills that you need to learn. So there's that.)

On which point... you'd need to look at the code to see what it does. You've given the name as Bedrock.Cube.Data.Clear which, you will doubtless be advised, is not the current version. It could be version 2, or it could be version 3. It won't be version 4 because that is }bedrock.cube.data.clear, note the leading brace and the lower case syntax for Linux types. The help page that you've pointed to relates to version 4.

Interestingly in version 3 (or the copy that I have) the absence of a pFilter argument leads to a ProcessQuit statement, not to the clearing of the entire cube. If you want to clear out the entire cube you need to pass to the parameter the text "Clear Cube"... which is a sensible precaution. This is different in V4 but to be honest I haven't looked much at V4 since I decided to move to my own set of generic processes. In the V4 process it looks like it was SUPPOSED to quit if there was no view AND no filter, but the ProcessBreak line is commented out. However that's academic since from the process name you're clearly using an earlier version.

Just to be clear, though, when you're talking about it writing back in the Data tab, this is something quite separate to the Bedrock process. You make the call to the Bedrock process in the Prolog, and the Bedrock process is a "black box" which "does something"; in this case zero out some data. Any code that you have in the Data tab will execute and write whatever you've defined (the code in your first post) regardless of whether the Bedrock process succeeds or not.

Me too, I use my own generic processes. They are often more generic than what is provided in Bedrock. The only times I use Bedrock, is the typical "export data/turn off rules calculations/import data again". I never use it in production environments. Changes in versions can be problematic, yes.

Have been using my own as well for years.

I have mulled over whether to respond to this post. There's obviously some pros and cons to stirring any potential controvercy, but I think there's enough benefit to rebutting/debunking some of the points above that it should be done.

Yes I guess I do have a vested interest as although I have actually written very very little of the current bedrock v4 code I am managing the project, maintaining on GitHub, doing some review & QA of pull requests and coordinating resources.

1. It's a bad thing that there are constant updates
While it is true that the main development branch / master branch is evolving with fixes and new features, a lot of effort goes into maintaining backwards compatibility (that is, if a process is called with the same parameter values then you get the same result, unless of course there was a bug in the previous behaviour). Issues are generally fixed quite fast, why leave a bug when it can be addressed?

2. It's failed on me too many times
As per the example provided by the OP in this thread in 99% of cases errors or unexpected results when running bedrock processes occur due to wrong parameter values being passed to the process (e.g. most commonly incorrect element names, missing or wrong delimiters, malformed filters). Or in other words the error actually occurs in the organic interface between the keyboard and screen and not in the code. In the cases where the library has a bug (and of course as with any software there are bugs, and probably lots of them!) the project on GitHub has a good record of addressing issues quickly. Most issues which are classified as bugs are fixed in a matter of days. As with any software and especially open source projects the continuous cycle of feedback and improvement is what makes the software robust. It's easy and only takes seconds to log an issue, and contributions are always welcome! If you are capable to identify and fix an issue yourself then this is always appreciated and actively encouraged.

3. I (prefer to) use my own generic processes
Nothing wrong with this. And obviously there's some benefit to knowing exactly what the code does becasue you wrote it yourself versus having a black box that just generates a predicatble outcome with a known input. However, almost all software is by definition a black box! The main thing (only thing?) that matters is the predicatable result and good performance. Regardless of personal preferences (and sometimes corporate restrictions that might mandate no open source, although that's much rarer these days) I would really hope that we can all agree on 2 things:
- it doesn't make sense for everyone to develop and maintain their own private TurboIntegrator function library
- a decen't TI library was missing from the TM1 community for a long time and adds value. It's up to the community to fill the gap. If a open source library has flaws then it's up to the community to pitch in and address them

4. GitHub is complicated and for programmers. I'm just a TM1 developer
Yes contributing via git is not as easy and straightforward as many of us would like (especially resolving code conflicts!). But neither is it that difficult and signing up and being able to submit an issue or download the code is dead simple and take no time at all. Even if maintaining / contributing code is too much, the contribution of issues and feature ideas is equally important and can can be done by anyone

@Admins, could you please split this topic to 2 topics: "CellPutN erase other elements value" and "I've also have my own processes"? There is still an unanswered question by OP, and it is drowned by bedrock's discussion.

(My post is also to be moved to another topic, please )
I know that everybody_above's posts were not to offence somebody, but this really looks like "Nobody needs your bedrock, I have mine". So my 4 cents on this:

• As for me, "I have mine" stable bedrock v3, with all bugs fully corrected. So, if v3 was on github, I could pull my corrections... Now, bugs in v4 are corrected earlier than I encounter them. There were real bugs in pre-4.1 versions, but now it's really stable, and issues are minor.
• There are really few developers or companies who have enough time (and experience..) "to have their own processes". For many TM1 developers, bedrock processes are rescue
• There is a point I don't like with Bedrock: it relaxes developers. Some developers and administrators use bedrock processes without understanding how they work.
• Another unobvious use of Bedrock processes - is their.. let's say... "Beauty". It's really a very well implemented, optimized and documented library of TI processes. I have a standard task for Junior developers: take some complicated Bedrock process, analyse it, understand how it works and describe it for me. Really, very useful to teach and to test knowledge.

So, thank you much, guys. You do very much for the TM1 community.

I just wrote a long answer for this topic and just as I wanted to post it the thread got split.

So now you will only get a shorter version of my opinion.

• Bedrock is great stuff and we can learn so much from the code

• Bedrock is really dangerous because people suddenly think they can do certain things with tm1 but do not fully understand the consequences due to a lack of tm1 knowledge. (That is true for any other form of standardization as well!)

• I never implemented it into a real life project so I can't say to much about how robust they are in production. But I think they should be pretty solid.

• My own processes fail me all the time. That is part of the job I guess.

• This discussion motivated me to implement them in the next project I start from scratch. I have to figure out a way to combine them with my own stuff. We will see where this goes....

• Regarding the GitHub stuff... Get used to it. The server is getting it as well.

scrumthing wrote: ↑Wed Sep 09, 2020 9:21 pm I just wrote a long answer for this topic and just as I wanted to post it the thread got split.

Sorry about that, but it shouldn't have actually affected your reply. I took a copy of the original thread (this is it) which went into a hidden forum, deleted the first post, changed the topic headings and moved this thread back into the main forum. The original thread (which you were presumably replying to) was unchanged save for me editing my own post to point it here, and deleting the subsequent posts which were duplicated in this one. That shouldn't have affected any replies to the original thread.

scrumthing wrote: ↑Wed Sep 09, 2020 9:21 pm So now you will only get a shorter version of my opinion.

There will be a longer version of mine in due course. For now I have other fish to fry, except for...

scrumthing wrote: ↑Wed Sep 09, 2020 9:21 pm

• Regarding the GitHub stuff... Get used to it. The server is getting it as well.

Mmm. I think you may be thinking of Docker, not GitHub. Though for mine both come under the heading of "cr@p I shouldn't need to do my job, which is providing planning and / or analytics solutions, not wearing a beanie with a propeller on it for the sake of it". If solution A allows you to achieve an outcome without wasting time learning peripheral technologies to get it running, and solution B doesn't... then in a world where every hour and every dollar counts, solution B has a distinct advantage. IBM failing to "get" this is one of the two biggest risks to the longevity of TM1; the other being its pricing model. But that is leaning in the direction of another thread split, so I'll leave that part there.

Hi all, Lotsaram,

Bedrock coding is very good. However, there are a couple of reasons/points to note about the usage of Bedrock in real TM1 models at customers:

1. I work for Aexis Belgium rather than Cubewise. Simple. It's not really a good idea if we are going to make publicity for competitors. As a small test, I just downloaded the Bedrock set of processes and did a search on that name: 331 hits in 168 files. EDIT: 186 hits in 89 TI processes in the MAIN folder. You see, I made an error against Git.

2. Bedrock is supposed to reduce the number of lines of coding. Looking at some of those processes, it's really beyond me why someone would ever use processes like "}bedrock.server.wait". Yes, there is logging and a few LogOutput messages. But all those TI processes, in my opinion, clutter up the TM1 server message log. Is said process such an improvement ? Compare:
to:
I do prefer the first option honestly. Drawing a mindmap of "what process executes what other process(es)" is a complete and utter mess with all the Bedrock processes involved (I wrote a generic TI process to generate such mindmap).

Or, this code:
and having/writing another process, rather than:
I do agree that most of the processes are useful and have a valid reason to exist.

3. If we refer to people's/company's own reusable libraries, it's certainly not always the same kind of processes. Indeed, it does not make a lot of sense to reinvent the wheel and write again another process to unwind a dimension. Looking at my own processes, they are more involved though. For instance:
- a process to set up a mapping (a custom mapping cube, text elements, custom rules, picklists, read security is applied, views and subsets for input and bad mappings, ...)
- a process to completely identify double countings (nog just the elements with multiple parents)
- a process to check the data source (whatever it is, like the correct number of columns in a text file and abort if not what is expected, etc.)
- a process to set up custom drill-throughs to level 0 in a cube
- a process to convert an Excel file to txt or csv instead of asking the user to do so

This is clearly beyond Bedrock programming. These processes might not be used as often as Bedrock processes but the time saved is so much bigger: they are also targeted to removing manual work for the developer and key admin people, and not only reducing time spent on writing code for the developer.

Below some statistics comparing Bedrock coding against my own TECHnical processes (used very much), other processes that are used less but still generic, and a couple of other ones. I'll leave the analysis for those of you interested. Yes, this cube is created with such a generic TECHnical process.
I posted a number of these TECHnical generic processes in the 'Tips and tricks' subforum here, although I tend to work on them and add improvements every once in a while.

Add to this about 46,000 lines of code in Excel VBA (not all TM1 related, though), 11,000 lines of code in Outlook VBA and 8,000 lines of code in AutoHotKey and you will understand that automation and using (reusable) code are important to me (in total about 120,000 lines of code).

4. Where the real power is/can be, is allowing for a parameter like pMode (numeric). A process can be written to create a dynamic level 0 subset. Why not having a parameter for the scope, next to a parameter pName for a text entry:

# The parameter pMode determines to what extend subsets will be created:
# If pMode = 0, you treat all application cubes and dimensions. pName is ignored.
# If pMode = 1, you treat 1 dimension. Specify the dimension name in pName (wildcards * and ? are allowed)
# If pMode = 2, you treat 1 cube. Specify the cube name in pName (wildcards * and ? are allowed)
# If pMode = 3, you treat all dimensions. pName is ignored.
# If pMode = 4, you treat all application dimensions. pName is ignored.
# If pMode = 5, you treat all control dimensions. pName is ignored.
# If pMode = 6, you treat all cubes. pName is ignored.
# If pMode = 7, you treat all application cubes. pName is ignored.
# If pMode = 8, you treat all control cubes. pName is ignored.
# If pMode = 9, you treat a number of control cubes related to security. pName is ignored.
# If pMode = 10, you treat all control cubes related to security. pName is ignored.
# If pMode = 11, you treat a number of control cubes related to statistics. pName is ignored.
# If pMode = 12, you treat all measures dimensions. pName is ignored.
# If pMode = 13, you treat all dimensions specified in a subset called 'auto subsets' (hard-coded value in this process). pName is ignored.
# If pMode = 14, you treat all cubes specified in a subset called 'auto subsets' (hard-coded value in this process). pName is ignored.

For an experienced TM1 developer, writing this is not the end of the world, but it can be useful. Or allow for a parameter pLanguage since not all of us speak English. A Default view is called like that in English, but it will not show up as Default if the user has a different UI language like French. https://www.wimgielis.com/tm1_userinter ... ges_EN.htm

5. In real life TM1 models, we (I) very often see that a generic process just does not fit in perfectly. More often than not, a process needs to do "almost" what the generic process does, but also needs to do a few other things (like updating an attribute for instance). We can change the generic process but then we deviate from the Bedrock coding, so in the end we give up and switch to a new process.

6. Some processes are just too "heavy", in the sense that they can do so much, but using them for simple tasks will actually lead to slower executions. For example, I can imagine that a generic copy process with all kind of checks and also IF-structures to check for the number of dimensions, will/can be slower than just doing the CellIncrementN in the data tab of a process. I did not test this, but I am confident that this can be the case.

7. I do appreciate a platform like Git. The cons that have been talked about, they do not outweight the pros, at least not in my opinion. I prefer this solution rather than the old static website for Bedrock, even though I had to learn some Git skills too.

8. (I add this point number 8 some time later) What I notice in my own reusable library: there are a lot of parameters and functionality in the processes. It allows for a big number of possible combinations, given parameter values. Testing the processes is not always the most interesting part of the job (sigh) and we all know what that means or can mean. From time to time it happens that I run into an error at the customer site, fix it very quickly or just do the task manually, and the real check/test happens a couple of evenings later. My processes become bigger, and this problem is likely to occur more and more. Certainly with new core server additions like hierarchies. The pMode example above actually should be extended for hierarchies... it becomes a never-ending story even just to follow up.

{I note that Wim has covered some of the things that I mentioned below, but I'll keep everything in place since I've already dictated it.}

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm I have mulled over whether to respond to this post. There's obviously some pros and cons to stirring any potential controvercy,

Happy to oblige.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm1. It's a bad thing that there are constant updates
While it is true that the main development branch / master branch is evolving with fixes and new features, a lot of effort goes into maintaining backwards compatibility (that is, if a process is called with the same parameter values then you get the same result, unless of course there was a bug in the previous behaviour). Issues are generally fixed quite fast, why leave a bug when it can be addressed?

I wasn't talking about bugs. I was talking about the fact that making the library dynamic by making it open for every Joe Admin to add new processes, change parameter meanings, add new parameters, etc, etc, means that the "bedrock" on which your code is built can change depending on when you last downloaded it, and who last updated it. Sure, you may do backward compatibility testing on modified process A. I assume you've also tested the effect on every process that calls process A? And every process that calls that process? Because potentially you've got (based on my last download) 82 processes to test. I'll come back to that point. And you would need to have anticipated every possible value that can be passed to each parameter. In a static library at least you know exactly what is going to happen when you do X. With an ever changing library, with all the good will and best effort in the world - and I don't doubt that you apply both - you can still end up with "SURPRIIISSEE!" when you run a recently updated process. Then of course there's the fact that part of the dream of a community library is that everyone would use it, making it easy to move from site to site. (No way will that happen as things stand, but I'll come back to that as well.) But let's assume that it becomes fairly widespread. So you have a consultant who writes some code which calls the Bedrock 4 processes on the server at company A. He or she takes that code, loads it up into company B's server thinking "Oh this will be easy" and BOOM! Why? Company B had the Bedrock 4 version that was created in July, while company A has one which was updated in September and included new processes or parameters.

Oh, that's an easy fix, just download the latest version onto company B's servers. And hope to the gods that that doesn't break something else. Or, alternatively, read through eeeevery updated process and test that it DOESN'T break something else.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm 2. It's failed on me too many times
As per the example provided by the OP in this thread in 99% of cases

One instance proves that it's a 99% error rate on the part of the user. Yes, I too love that 99.328% of quoted internet statistics are rectally obtained, just like my one there was.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm errors or unexpected results when running bedrock processes occur due to wrong parameter values being passed to the process (e.g. most commonly incorrect element names, missing or wrong delimiters, malformed filters). Or in other words the error actually occurs in the organic interface between the keyboard and screen and not in the code.

{Sigh}, yeah, it must have been me screwing up.

When I said "it's failed on me too many times" the actual number could be counted on two hands. Yes, I probably should have chased down what the errors were, but in each instance when it failed my main priority was time. So my alternatives were to debug the code, or just write my own. In the end I found the second to be the better option and again, I'll come back to one of the key reasons for that.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm 3. I (prefer to) use my own generic processes
Nothing wrong with this.

And yet only a paragraph later, "we all agree " (ah, no we don't) that this "doesn't make sense".

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm And obviously there's some benefit to knowing exactly what the code does becasue you wrote it yourself versus having a black box that just generates a predicatble outcome with a known input.

Except when the predicted outcome does not occur, which was my infrequent-but-frequent-enough-to-matter-to-me issue.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm However, almost all software is by definition a black box!

Bedrock isn't since you can, by definition, see the code. The context in which I used the term in my original post is that the Bedrock call "does something" but that HOW it does that is not germane to what happened in the data tab. It was neither a positive nor a negative judgement, just something that "is".

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm I would really hope that we can all agree on 2 things:

No, we don't.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm - it doesn't make sense for everyone to develop and maintain their own private TurboIntegrator function library

Here's why I COMPLETELY disagree with that.

Bedrock tries to be all things to all people. As a result of that you end up with a massive amount of bloat; 82 processes, many with interconnections between them. And a lot of it is clutter, yet you need to be across all of it to be sure that any given process will do what you need it to do, even when there is no earthly need to ever call the process in the first place. }bedrock.cube.create, for example. Why on EARTH would I ever need a process to do that? It's ONE line of code to create a cube, for heaven's sake, and when you do it directly there is no need to faff around with making sure that you have the parameter strings nicely delimited with the right delimiter character. Oh but wait, it can also RECREATE a cube. Fine, that's between two and FOUR lines of code if you do it directly. Except... I for one always check the return values of any processes that I call, so the "saving" disappears anyway. Ditto with }bedrock.cube.delete. Ditto with }bedrock.cube.view.delete. Ditto with }bedrock.server.savedataall. Ditto with }bedrock.security.group.create, Ditto with... I could do this all day, but I won't. Then there are processes like }bedrock.dim.attr.importfromfile, something which I've done maybe once in the last decade and took me something like 5 minutes to write a process for. Yes, I know that some of those are there for other Bedrock processes to call. That doesn't make Bedrock bad, but it makes vast swathes of it unnecessary for many, perhaps the majority, of users, except for complete newbies who can learn from it.

{Wim's similar comments are noted.}

How many generic processes do I have? 10. It will eventually expand to just under 20. I also have some blocks of standard code in Arc, admittedly, but those are inserted in line. The 10 represent repeatable tasks that I do on a regular basis. ONLY on a regular basis. Not on the remote chance that I may want to do it once a decade. It is far easier to keep track of 10 processes than 82. It is far CLEANER to have only 10 processes in your process list than 82, although Arc's filtering ability makes the length of the process list less relevant. (But not in Perspectives, it isn't.)

And more importantly... Bedrock tries to be specific to nobody (which it has to), but as a result it IS specific to nobody. My 10 processes update the control objects that I use to run my servers in a way that Bedrock will never be able to, by definition, because those objects are specific to my models. There are ways of working around this to add your own code to Bedrock code, but at that point it starts to defeat the point of the exercise. This is why it can in fact be useful for everyone to develop a library which is specific to their own models, IMHO.

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm - a decen't TI library was missing from the TM1 community for a long time and adds value. It's up to the community to fill the gap. If a open source library has flaws then it's up to the community to pitch in and address them

Yyyyeah. OK, let's talk about rooms and elephants. Some of the other members who are consultants may not want to bring this up because they don't want to start a feud, but I don't have a dog in this fight so I'm free to point out the obvious. (However I note that Wim beat me to it.) This is a "community library" in theory only. Every single process has "Cubewise Code" embedded inside it because you have it hosted on the Cubewise Code GitHub. If one of your competitors is at one of their customer's sites, do you REALLY think that they are going to install a "community library" on their customer's server so that eeeevvvery single time the customer opens a Bedrock process, there is a de facto ad for one of the consultants' chief competitors staring them in the face? I'm going to go with a hard "No" on that one. That being the case there is NO chance, whatsoever, of this ever being a universal community library. If it came from IBM, then maybe. Of course if it came from IBM it would probably be cr@p because IMHO IBM is legendary on the server side and largely clueless (with some exceptions) on the client side, whereas Cubewise does write excellent client code as things like Arc and Pulse attest. But there is NO WAY that Bedrock is ever going to make its way into any client which uses a different contractor and in that respect this will forever NOT be a real "community" library, but something generously gifted by Cubewise... but which also acts as a promotional tool for you. Do not think for a second that this is some new discovery on my part. This has been noticed. And commented on. (Again, Wim beat me to that.)

lotsaram wrote: ↑Wed Sep 09, 2020 1:36 pm 4. GitHub is complicated and for programmers. I'm just a TM1 developer

Nice way to twist my words there. Let me be clear about what I am saying, and bear in mind very clearly that I, like many people here, am not "just" anything.

If the Covid experience has taught us nothing else it SHOULD have taught us the value of time. The value of being able to look at what we want to achieve, and the resources in time, money, attention and opportunity cost to get there. I have spent a lot of time in my life chasing down things that have, in the end, turned out to be dead ends not to mention boring, tedious and ultimately pointless. C, Java, Adobe Premiere, programs that I don't even remember the names of now. Then there are the things beyond sitting in front of a screen. One year ago today I was in London en route back home to Roma, and it SEEMED that I could go back there any time I had the time, money and inclination. Now, we know differently. Not only has this thing delayed many things that we may have wanted to do in life, it has reduced significantly the number of opportunities that we'll have to do them. So now, before I commit myself to spending time learning something new, or doing a task, I ask myself "Will this help me do my work in less time?", or "Will this help me achieve a goal? Is it the BEST option to achieve that goal?"

Github skills are not required for my work. They are not required for my personal projects. They are not interesting in their own right. They are a boring, tedious sideshow which would only ever be used to create forks or whatever for Bedrock, something which I cannot see myself doing on a regular basis. And if you don't do something on a regular basis, you forget how to do it and you have to relearn, albeit that the relearning may be faster.

This is the same with my issues with Docker. Let me be clear that I do not actually give a flying fig about Docker itself and whether the clients or the server use it. Could. Not. Care. Less. What I care about is that the installation manual for TM1 is 414 goddamn pages long, and that the installation process for PAW and PThisWeek'sNameForExcel involves downloading bits and pieces from here and there and running Powershell scripts and figuring out connection strings that never sodding work... while installing the full stack of SQL Server might, on a bad day, take 15 minutes of walking through a guided installation dialog, and filling in prompts, after which the server is up and running and I'm productive.

I am not paid to install TM1, it's just something that I need to do to get to what I DO need to do. And I resent the way it Wastes. My. Time. Similarly, learning Github would Waste. My. Time. I have no use for it, most admins probably have no use for it, so learning all the arcane Github skills to faff around creating Bedrock updates is time that those of us who don't use or need GitHub for other purposes have lost.

Let me also be clear on this; I think that the Bedrock library is an awesome achievement with some very good coding in it. HOWEVER my preference now, in part guided by my post-Covid philosophy above, is to move my models to a more "minimalist" approach. I need to keep my "library" tight, lean and "at a glance" comprehensible. I need to be sure I know what my library processes do without needing to go and look it up or read through the code and I need to know, without doubt, that each process will work because I know exactly who updated it and when.

Nobody EVER said "Nobody needs Bedrock because I've got mine", though some of us prefer not to go the Bedrock way (in my case "any more"), and it's pretty certain that your competitors will never use it.

I just wanted to say that I have been using bedrock TI (up to v4) professionally as a TM1 consultant/developer for at least 10 years in a large number of organisations, in big production environments and cannot think of a single instance of any of the processes malfunctioning. Every time I thought it did, I realised my own parameters/syntax/usage were at fault.

It is a truly wonderful, 100% free resource that, if you learn to use it properly and trust the Cubewise people behind it, can not only save you huge amounts of time and effort but allow you to responsibly develop models that other developers can quickly understand. To those who criticise it, I suggest you thoroughly examine your own motives and practices and see if it is actually yourself at fault.

To those who develop your own suites of custom processes, well done but spare a thought for all the TM1 ers who will in future have to find out whether a malfunctioning process is down to your code. On that latter point, bedrock has a very large user base and a fully documented, publicly available online presence and is thus far less likely to contain bugs. So be fair people.

iansdigs wrote: ↑Thu Sep 07, 2023 9:11 pm To those who criticise it, I suggest you thoroughly examine your own motives and practices and see if it is actually yourself at fault.

Eeeh, "offensive", "insulting"... not sure. One of them, I suspect, plus a couple of other adjectives I can think of. Wim and I gave hard, thought out facts as the basis for our arguments, but hey, what's that compared to "vibes" and a demand that we examine our motives to see our faults, our faults, our grievous faults?

iansdigs wrote: ↑Thu Sep 07, 2023 9:11 pm To those who develop your own suites of custom processes, well done but spare a thought for all the TM1 ers who will in future have to find out whether a malfunctioning process is down to your code. On that latter point, bedrock has a very large user base and a fully documented, publicly available online presence and is thus far less likely to contain bugs. So be fair people.

Way to not read what we wrote (three years ago), Ian, since at least one of the main points has a direct bearing on your claim of it "allow(ing) you to responsibly develop models that other developers can quickly understand".

The key point, THE. KEY. POINT. is that if Bedrock was still maintained entirely in house by Cubewise such that each release was an unvarying quantity that could be comprehensively tested, there would be a degree of certainty about the functionality for that version of it.

As it was released into Github and can be modified by anyone at any time, the functionality can change, the parameters can change, the same alleged "version" can vary in significant ways from other downloads of that "version". And in that instance, those "future TM1ers"? Thye'll still have to figure out what the processes are actually doing, since the functionality may not be what they are used to in the instance of the library that they were previously using.

(OK, I'll concede that that's *A* key point. The multitude of others that Wim and I mentioned are also relevant.)

Since necromancing multi-year old threads seems to be the fashion of late, I thought it might be relevant to point out another detail that has evolved in lo these many years since this thread came up. That is, the development of Arc into an incredibly mature and powerful tool, one which has made libraries less relevant because of one key feature... code snippets. (And also code templates.)

Three years ago they worked, and worked well, mostly. Three years later, they kick butt with a steel capped toe.

I said that my custom library consisted of between 10 and 20 processes. The number is now closer to 10 than 20 because code snippets have made some of the things that they used to do redundant and "to be fair" to the poor, put upon theoretical future TM1ers, if they can't wrap their head around 10 processes rather than 83, I would question whether they should actually be doing TM1. Or anything that doesn't involve coloured pencils.

Things like creating a subset, any flavour of subset you like - element level, single element, whatever - can be done by typing the word "subset" in Arc and selecting the relevant @ block, then just changing the values. This is the sort of thing that could, back in the ancient days, be justified as a library process on the basis that it saved needing to look up all of the syntax and retyping it. Now it's "type 6 characters, point to the code snippet, press Enter", and {bang}. The poor put upon theoretical future TM1er doesn't need to recall which library process to call, doesn't need to remember the parameters, doesn't need to compile the arguments... the code is right there, in line, clear as day. It means that there is no (admittedly minimal) overhead from the server needing to call another process. It means that the server log isn't cluttered up with cr@p indicating a process call to execute 1 lousy line of code. It means that the code is closer to being self documenting.

Don't have one that does what you want? Easy, write your own. Poor, hard pressed future TM1er doesn't need to know your code snippets because they generate in line code anyway. For all he or she knows, you typed it.

"But wait!", I may hear some people say, "This isn't relevant to those who don't use Arc! They still need libraries."

That is indeed true, in which case the original discussion is still relevant to you. (To some extent it's also true for the diminishing number who are still on 10.x or earlier as well where the restful API was either primitive or non-existent, though for those who are still back there whyyyyyyyyy????. (Rhetorical question.))

But if you're a TM1 developer and you aren't using Arc... sorry, but it sucks to be you and I say that with as much compassion as I can muster. (Which isn't bucket loads I grant you, as someone who shells out for the tool out of my own pocket, such is its value to me.)

Alan Kirk wrote: ↑Fri Sep 08, 2023 12:00 am The key point, THE. KEY. POINT. is that if Bedrock was still maintained entirely in house by Cubewise such that each release was an unvarying quantity that could be comprehensively tested, there would be a degree of certainty about the functionality for that version of it.

As it was released into Github and can be modified by anyone at any time, the functionality can change, the parameters can change, the same alleged "version" can vary in significant ways from other downloads of that "version".

My only contribution here would be to point out that this is not true Alan, and you should know that. So I'm not sure which axe you are grinding.

Bedrock is on GitHub which means that
- anyone can fork it and create their own version
- anyone can create a pull request for a bug fix or enhancement
- in escence anyone can contribute (and is more than welcome to)

However what it doesn't mean is that there is a free for all with anyone and everyone able to make random changes.
What people do in their own forks stays in their own forks and does not affect the bedrock master library. That is unless they make a pull request which is reviewed, accepted and merged by a maintainer (which is a very small set of people with this access, basically it has just been me for the last couple of years. I am essentially the gatekeeper or bottleneck.)

iansdigs wrote: ↑Thu Sep 07, 2023 9:11 pm I just wanted to say that I have been using bedrock TI (up to v4) professionally as a TM1 consultant/developer for at least 10 years in a large number of organisations, in big production environments and cannot think of a single instance of any of the processes malfunctioning. Every time I thought it did, I realised my own parameters/syntax/usage were at fault.

We should certainly fork this thread if there's merit to that.

I wanted to add that I vividly remember this discussion back in 2020 soon after we went live with our solution that relies on Bedrock. This thread made me a bit nervous at the time to be honest. But let's get down to the facts rather than feelings on Bedrock. For our environment, we have used Bedrock processes (with pride-I've presented on this point before) in production since 2020. As of this posting, it has executed 45,232 times with ZERO errors.

Few things come to mind:
(1) Not sure why there's unnecessary criticism toward Bedrock. As said, it's 100% free incorporating the knowledge and wisdom of the best and brightest talent in TM1--great value. As per above, it works. It's maintained by the best-of-the-best, none of this "anyone can change the code" makes sense to me.

(2) Extension on the last point in #1, much of technology relies on publicly available, free libraries. Not sure much tech nowadays creates the own unique libraries independently. Folks shouldn't feel the need to reinvent the wheel for trivial tasks, they should focus on bringing the best possible experience to end users through TM1.

I'm with lotsaram and Ian here.

Should there be a bedrock or something like it? Yes, and use it or not as you like. It's presence on a model would at the least be a marker that the developer had thought through his or her options.

Is it a pain that Cubewise is advertised in the code? Well, maybe yes to some consultancies, but it's not a problem for the rest of us, and I don't see any other consultancy stepping up with the resource that Cubewise have for this - I don't know what lotsaram's charge out rate is, but I'm guessing it's a lot (and no I don't work for Cubewise!).

Should bedrock be on Github? lotsaram's reply seems eminently sensible, and I can't think of another suitable way of getting non-Cubewise resource to be a part of building and maintaining it. Arc seems to me, fine as it is, to be a different and much more commercial beast that fits in with the ecosystem that Cubewise are building (Pulse, Slice etc).

Mention of TM1py, also open source, is missing from this discussion, but imho it's one of the key developments (hand in hand with the introduction of the REST API by Hubert) in TM1 for a long time and kudos to Cubewise for resourcing and championing it - and I find it hard to imagine another way of developing it than via Github.

lotsaram wrote: ↑Fri Sep 08, 2023 11:27 am My only contribution here would be to point out that this is not true Alan, and you should know that. So I'm not sure which axe you are grinding.

The closest I'm coming to grinding an axe is in relation to a guy who hasn't shown his face here for a couple of years creating a new account, digging up a 3 year old thread, and making one, count them, one substantive point (which, had he bothered to read the earlier parts of the thread, he would note had been disputed there), ignoring every other issue raised, and questioning the competency and motives of other people in the thread.

Don't like that. Don't like that very much at all.

On said substantive point:

lotsaram wrote: ↑Fri Sep 08, 2023 11:27 am Bedrock is on GitHub which means that
- anyone can fork it and create their own version
- anyone can create a pull request for a bug fix or enhancement
- in escence anyone can contribute (and is more than welcome to)

However what it doesn't mean is that there is a free for all with anyone and everyone able to make random changes.
What people do in their own forks stays in their own forks and does not affect the bedrock master library.

That is unless they make a pull request which is reviewed, accepted and merged by a maintainer (which is a very small set of people with this access, basically it has just been me for the last couple of years. I am essentially the gatekeeper or bottleneck.)

OK, fine. As long as there is someone who's maintaining central control, and as long as (I'm assuming) you use version numbers with each functionality change to maintain a versioning system, then I concede that point.

Adam wrote: ↑Fri Sep 08, 2023 1:53 pm I wanted to add that I vividly remember this discussion back in 2020 soon after we went live with our solution that relies on Bedrock. This thread made me a bit nervous at the time to be honest. But let's get down to the facts rather than feelings on Bedrock.

All the things that were mentioned in the previous posts? Those things were facts.

Adam wrote: ↑Fri Sep 08, 2023 1:53 pm For our environment, we have used Bedrock processes (with pride-I've presented on this point before) in production since 2020. As of this posting, it has executed 45,232 times with ZERO errors.

Just a reminder, this thread is three years old. First, I had been working with Bedrock since version 1 came out. And I encountered errors. Not, "Error log for Bedrock process x errors", just "it didn't do what the documentation said" errors. That doesn't mean that they were in the version that you have been using since 2020. I can't even recall what the version was, since I had abandoned Bedrock before you even picked it up. But they happened. And when you have 80+ functions in a library created over a period of years, across multiple versions, it would be more surprising if there weren't errors somewhere along that journey than if there were.

Adam wrote: ↑Fri Sep 08, 2023 1:53 pm Not sure why there's unnecessary criticism toward Bedrock.

Not sure why you think that lists of reasons not to use it is criticism, much less that it's unnecessary criticism.

Adam wrote: ↑Fri Sep 08, 2023 1:53 pm Extension on the last point in #1, much of technology relies on publicly available, free libraries. Not sure much tech nowadays creates the own unique libraries independently.

We're not talking about a language like Python. TI is as limited as it is archaic. TI libraries do not extend the functionality of TI, they simply package up repeatable code, and there are other ways of "not reinventing the wheel" that don't require library functions. Certainly not library functions to execute a single line of code in the native language which, as I noted three years ago, many, many of the Bedrock functions do. The advantage of (an ideally limited) range of home created libraries of functions is that they can work with objects which are specific to your own model designs. But then, that had already been discussed three years ago.

Paul Segal wrote: ↑Fri Sep 08, 2023 2:16 pm Should there be a bedrock or something like it? Yes, and use it or not as you like. It's presence on a model would at the least be a marker that the developer had thought through his or her options.

And its absence would suggest that they haven't? I'm pretty sure that the 2020 discussions covered the possibility that someone could have thought through their options and decided that this wasn't one that they wanted. I for one don't want to clutter my process list with 80+ functions that I don't need (because, Arc and because in too many cases 1 line of in line code beats a process call and its parameters) and will never use just to demonstrate that I've considered my options.

Paul Segal wrote: ↑Fri Sep 08, 2023 2:16 pm Is it a pain that Cubewise is advertised in the code? Well, maybe yes to some consultancies, but it's not a problem for the rest of us,

Again, the consequences of this were discussed 3 years ago but if a greenfield site were to get in a non-CW consultancy, they certainly won't be implementing Bedrock. So the dream of having a "universal" library which will appear on every instance everywhere? Ain't happening. That's not a "problem", or at least I don't consider it to be one, but it's a reality.

Paul Segal wrote: ↑Fri Sep 08, 2023 2:16 pm Mention of TM1py, also open source, is missing from this discussion,

Yeah, because... three years old and all that.

Paul Segal wrote: ↑Fri Sep 08, 2023 2:16 pm but imho it's one of the key developments (hand in hand with the introduction of the REST API by Hubert) in TM1 for a long time and kudos to Cubewise for resourcing and championing it - and I find it hard to imagine another way of developing it than via Github.

Except that TM1Py is a completely different kettle of fish. It's something that was created outside the TM1 environment. The question of whether TM1Py could be used as a replacement for TI is, I believe, one that is being had in some quarters, but that really should be its own discussion.

Yes, it's been 3 years. Time flies and IBM is coming to rescue:
PAW with your own custom snippets (https://www.ibm.com/docs/en/planning-an ... ess-editor)

Wim Gielis wrote: ↑Sat Sep 09, 2023 3:41 am Yes, it's been 3 years. Time flies and IBM is coming to rescue:
PAW with your own custom snippets (https://www.ibm.com/docs/en/planning-an ... ess-editor)

Interesting, but it's not exactly the 7th cavalry, I'm afraid. It's only for people who can get PAW working (and I admit that our uber-locked down environment doesn't help with that) or who could tolerate the idea of working with PAW (and I admit that such a concept is beyond me, and forever shall be, but let's not go there.)

But I note that they talk about what categories of snippets "are currently available", not about creating your own or customising them.

{Sucks air through teeth and looks up...} Yyyyup, that's IBM alright.

I should have added emojis to my post as we all know that you are not the biggest fan of PAW It was meant to be funny and certainly not as viable option beyond any work done for fun or demo purposes.

But anyway, for completeness, custom snippets can be created. https://www.ibm.com/docs/en/planning-an ... om-snippet