[sologoub]

Thanks!

The reports are all API driven. User specifies dimensions and metrics, as well as filters, etc. The API returns the JSON response.

I can't predict what users will want to visualize in the future, so dedicated templates for each of the visualizations are not practical for my use case.

The goal is to minimize dev work on the API and let front end config dictate what columns the API returns.

[ksri]

Let's assume you have a python object "userquery" that has the user specifications - including dimensions, metrics, filters and the cube to query. I'm also assuming you have whitelisted all the parameters in this object per your database model, otherwise you are open to security issues.

Here's how you could write that in jinjasql. I'm writing this out of memory, and it has errors/issues - but I hope you get the idea.

    SELECT
    {% for metric in userquery.metrics %}
        {{ metric.id }} as '{{metric.description}}'
    {% endfor %}
    FROM {{ userquery.cube }}
    WHERE 
    {% for filter in userquery.filters %}
        {{ filter.key }} {{ filter.operator }} {{ filter.value }}
    {% endfor %}
    GROUP BY 
    {% for dimension in userquery.dimensions %}
        {{ dimension }}
    {% endfor %}

This way, your template doesn't have to map to exactly one visualization.

Now, another interesting this in the security aspect. You can also pass the logged in user data model, and then append a where clause that restricts the rows based on the logged in user id or his role or whatever else is your application security model.

I'm not sure how much effort it would have saved you, but it does help us a lot - mostly because we don't have to translate between SQL and the way SQL ALchemy / ORM works.

[sologoub]

Thanks for the example, this helps a lot in my understanding of this!

It's pretty similar to what I did, but the template would be a lot more complex due to various column definitions and calculations, for example uniques require the base query to have the IDs of whatever I'm counting, but all in all I see the use case.

[sheeshkebab]

Is that safe from sqli prospective? It would inject table name and all, which I believe you can't bind...

[ksri]

You're right. That's why I said upfront - whitelist values in the userquery object.