Hi folks!
I have a specific scenario where getting a list of all dimensions available in a view into a Liquid variable would be extremely helpful. As of now, we have been using an `allDimensions` list manually written 😅. For context, this would be inside an `sql:` field the very same view.
Is there any sort of way of doing something such as this? Or, event better - a list of all dimensions that are _in_query?
My worst case scenario solution is to find an endpoint that I can hit to at least programmatically generate this list and update it every once in a while.
Appreciate any help!
What is the goal here, Enzo?
Hi! Thanks for looking into this, @GavinW! To explain it a bit better:
Right now, we have this list that is manually updated with all dimensions and measures in the Explore:
{% assign allDimensions = "dimension1,dimension2,dimension3,active_users,total_views,revenue" | split: "," %}
The reason this is particularly important is that we use different underlying tables based on which dimensions are being used in the query. For example:
- Our summary table supports: dimension1, dimension3, active_users, revenue
- Our raw table supports: dimension1, dimension2, dimension3, active_users, total_views, revenue
Note that our summary table is generated by a separate tool external to Looker.
So if someone includes dimension2 or total_views in their query, we need to use the raw table instead of the summary table. Right now, we're doing this check with our manual list:
{% assign rawTableRequired = false %}
{% for dimension in allDimensions %}
{% if events[dimension]._in_query %}
{% unless summaryTableDimensions contains dimension %}
{% assign rawTableRequired = true %}
{% endunless %}
{% endif %}
{% endfor %}
rawTableRequired is used after to decide which table to query from.
This works, but it requires manual updates whenever dimensions change. I'm wondering if there's a way to:
- Dynamically get all available dimensions in a view, or
- Get a list of dimensions that are actually being used in the current query
Either/both solutions for above would be extremely helpful not only here but in other similar patterns we face, where we change SQL based on dimensions/measures in use.
Hi could you please help me with mine ?