Bedrock And Github vs Other Options

Post Reply
creahui
Posts: 4
Joined: Thu Jul 28, 2016 10:33 am
OLAP Product: TM1
Version: 11.7
Excel Version: 2016

Bedrock And Github vs Other Options

Post by creahui » Fri Aug 28, 2020 6:49 am

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

User avatar
Alan Kirk
Site Admin
Posts: 6187
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Bedrock And Github vs Other Options

Post by Alan Kirk » Fri Aug 28, 2020 7:29 am

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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

Wim Gielis
MVP
Posts: 2527
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1
Version: PAL 2.0.8
Excel Version: Office 365 - latest
Location: Brussels, Belgium
Contact:

Bedrock And Github vs Other Options

Post by Wim Gielis » Fri Aug 28, 2020 1:48 pm

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.
Best regards,

Wim Gielis

Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 112 TM1 articles and a lot of custom code
Newest blog article: Updating process line numbers with AutoHotKey

User avatar
PavoGa
Community Contributor
Posts: 434
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.05
Excel Version: 2013 PAW
Location: Cleveland, Tennessee

Bedrock And Github vs Other Options

Post by PavoGa » Sun Aug 30, 2020 2:07 am

Have been using my own as well for years.
Ty
Cleveland, TN

lotsaram
MVP
Posts: 3426
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Bedrock And Github vs Other Options

Post by lotsaram » 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, 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
Last edited by lotsaram on Wed Sep 09, 2020 3:40 pm, edited 3 times in total.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.

User avatar
Elessar
Community Contributor
Posts: 207
Joined: Mon Nov 21, 2011 12:33 pm
OLAP Product: PA 2
Version: 2.0.9
Excel Version: 2016
Location: Russia

Bedrock And Github vs Other Options

Post by Elessar » Wed Sep 09, 2020 3:15 pm

@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.
Best regards, Alexander Dvoynev

scrumthing
Posts: 49
Joined: Tue Jan 26, 2016 4:18 pm
OLAP Product: TM1
Version: 2.0.9
Excel Version: too many

Re: Bedrock And Github vs Other Options

Post by scrumthing » Wed Sep 09, 2020 9:21 pm

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

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. :P
  • 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. 8-)
There is no OLAP database besides TM1!

User avatar
Alan Kirk
Site Admin
Posts: 6187
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: Bedrock And Github vs Other Options

Post by Alan Kirk » Wed Sep 09, 2020 9:54 pm

scrumthing wrote:
Wed Sep 09, 2020 9:21 pm
:cry: I just wrote a long answer for this topic and just as I wanted to post it the thread got split. :cry:
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. 8-)
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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

Wim Gielis
MVP
Posts: 2527
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1
Version: PAL 2.0.8
Excel Version: Office 365 - latest
Location: Brussels, Belgium
Contact:

Re: Bedrock And Github vs Other Options

Post by Wim Gielis » Thu Sep 10, 2020 12:03 am

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:

Code: Select all

Sleep( 5000 );
to:

Code: Select all

ExecuteProcess( '}bedrock.server.wait', 'pLogOutput', 1, 
      'pStrictErrorHandling', 1,
	  'pWaitSec', 5
	);
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:

Code: Select all

ExecuteProcess( '}bedrock.security.refresh', 'pLogOutput', pLogOutput, 'pStrictErrorHandling', pStrictErrorHandling );
and having/writing another process, rather than:

Code: Select all

SecurityRefresh;
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.
01.png
01.png (43.29 KiB) Viewed 184 times
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.
Last edited by Wim Gielis on Thu Sep 10, 2020 3:29 pm, edited 6 times in total.
Best regards,

Wim Gielis

Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 112 TM1 articles and a lot of custom code
Newest blog article: Updating process line numbers with AutoHotKey

User avatar
Alan Kirk
Site Admin
Posts: 6187
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: Bedrock And Github vs Other Options

Post by Alan Kirk » Thu Sep 10, 2020 2:18 am

{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 pm
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?
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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

Post Reply