Commenting in Einstein Analytics

Wow, this sounds like a super fun topic, right? The first rule of the internet is never read the comments, but commenting your code is another story. Comments are the most helpful thing in the whole world, and I’m really bad about doing it. Commenting just means that you are adding short, normally single-line notes to your code. This can be used to explain what you’re doing or how something works, which is especially important if someone else is going to be looking at it. Or if you aren’t going to be looking at it for a long time – sometimes its hard to remember what you were doing 3 months ago, ya know? Another super useful way to use comments is to implement crazy requirements – like I so often have to do. Let’s get into it!

First, how do I comment in Einstein Analytics?

First thing – you can only comment if you are actually in the SAQL (or JSON). You can’t comment anything if you are just clicking – which remember – you should always do if you can! Clicks not code! But if you ARE manipulating the SAQL, commenting is super easy. You just add two sequential hyphens to the beginning of the line you want to comment. You could also put it at the end of a line.

--I can put my comment here because its cool.

q = load "myData"; --I can also put my comment here because that's cool too.

So when do you want to leave comments? NOT ALL THE TIME! Let your queries stand for themselves, but if you are doing something complex or something long where you wouldn’t want to have to read every line of code to understand it – then by all means – leave a comment!

--This is where we start a timeseries projection that will be used in some results somewhere.

--Start something here.

--I did this because I wanted to.

If you area leaving comments, they should be helpful. Or maybe drop a fun easter egg every once in a while 🙂

But this is really what I wanted to talk about

Leaving notes are great and I’m sure everyone understands why, but commenting is definitely more useful than that. I use commenting a lot, in association with static bindings, to do cool stuff. Let’s talk about a use case.

I’ve got a chart where I’m projecting some values by month – a year over year revenue chart. Simple. But now I want to switch the charts so I can see the difference between revenue and sales. I solve for that with a static query that updates the chart. Simple enough. Now I want another filter by business unit. This data is already coming from lots of different places – come static, some dynamic and filtering by business unit is complex, especially since we’re switching between revenue and sales already. So I solve for this with another static query. Again, simple enough. I’m also using this business unit filter to project an additional line on my chart for targets. But now I want to add another filter, where I can filter that target by different levels. I want to be able to toggle between good, bad, and ugly. I can’t keep using my business unit filter for that because now there’s more than one target per business unit – there’s 3 – and the requirement is really that this be a separate filter. So, what do we do? We comment!

Using comments, I can actually project all 3 targets from my business unit filter at the same time, but then comment out the ones I don’t need based on the new target filter. Is this all making sense? Let me show you!

This is my static step that will control the commenting, where the end user is choosing between “Good”, “Bad” and “Ugly”:

"target_toggle_1": {
                "broadcastFacet": true,
                "columns": {
                    "Display": {
                        "type": "string"
                    }
                },
                "label": "target toggle",
                "selectMode": "singlerequired",
                "type": "staticflex",
                "values": [
                    {
                        "Display": "Good",
                        "good": "",
                        "bad": "--",
                        "ugly": "--"
                    },
                    {
                        "Display": "Bad",
                        "good": "--",
                        "bad": "",
                        "ugly": "--"
                    },
                    {
                        "Display": "Ugly",
                        "good": "--",
                        "bad": "--",
                        "ugly": ""
                    }
                ]
            },

This is what the binding looks like in the actual query:

{{column(target_toggle_1.selection, ["good"]).asObject()}}target = foreach target generate {{column(revenue_toggle_1.selection, ["good"]).asObject()}} as 'sum_target';
{{column(target_toggle_1.selection, ["bad"]).asObject()}}target = foreach target generate {{column(revenue_toggle_1.selection, ["bad"]).asObject()}} as 'sum_target';
{{column(target_toggle_1.selection, ["ugly"]).asObject()}}target = foreach target generate {{column(revenue_toggle_1.selection, ["ugly"]).asObject()}} as 'sum_target';

Which translates to this when the query executes:

target2 = foreach target2 generate 1000 as 'sum_target';
 
--target2 = foreach target2 generate 800 as 'sum_target';
 
--target2 = foreach target2 generate 500 as 'sum_target';

You can see that the first line is not commented, and the next lines are commented, so the query only evaluates the first one, which is holding my “Good” figures. If the user were to select “Bad”, then the middle line would not be commented and the first and third lines WOULD be commented, so the query would only evaluate my “Bad” figure.

Wrap it up, lady!

Hopefully this all makes sense. Its been a great workaround on many occasions for me. Note that you would only really have to do this when you’re working with static data. If I were to load the same data as a csv dataset or something, then I could just use a binding to update the filters on that dataset like you would normally. This could also be used as a POC before transitioning to a full dataset if you wanted. The possibilities are endless, I’m sure.

Yay comments!