Question

Same dashboard/looks on different connections

  • 27 September 2017
  • 14 replies
  • 300 views

Userlevel 6
Badge

We are running an identical database environment which contains test data which isn’t considered live but is still real data.

A lot of people are interested in viewing this data so either want to use an existing dashboard to do this or create new content which can see both production and QA data.


Can this be done using parameters so in the dashboard the user can pick production/QA and then this filter value is passed into the connection declaration in the model file?


Can someone offer any tips regarding workflow around how best to do something like this if parameters wouldn’t work?


I have thought about lookml dashboards but these are tied to a model file and therefore a connection so we would end up with duplicated lookml file with different model file declarations, even if i extend the original dashboard I still need to list every single element & filter to override the modelname.


14 replies

Hello @IanT. There may be a few options to consider for this use case. If you don’t think these options apply please let us know more details about your use case and we can take another look.


For altering the table/schema name, you could use:



  • Parameters to change the table/schema names in sql_table_name:


For altering the connection parameter, you could use:


Userlevel 6
Badge

None of these points are going to resolve my problem.

We have 2 model files which are identical other than the connection name and we have 2 dashboards which are identical other than the model from which they are built from. Fieldnames and explores are the same since production and QA databases are identical.


I don’t want to have to maintain 2 versions of the same dashboard, ideally I have 1 which is capable of switching between the 2 connections.

Lookml dashboards are going to be a bit easier as it’s just a copy paste find and replace on the model name but this is not very automated.

Hi @IanT,


I was looking for a solution for you here but could not come up with anything decent. As you mentioned yourself dashboards are being build of the models, so there is no way currently to switch which connection/model to use as it is static. However with Lookml Dashboards you can do so, by replacing model: acme name parameter for all elements. It does include a bit of manual work though. I am just trying to understand your use case a bit more before I can file feature request to our product team. What is the downside of having two dashboards one per connection in your case?


Best,


Sasha

Userlevel 6
Badge

Any changes that need to be made need to be done twice which is likely to mean they end up drifting further apart due to errors in doing this.


We have been staying away from lookml db’s for as long as possible because of them not being available in spaces, I am aware they can be converted but this then adds yet another step to editing these 2 dashboards.

Hey again @IanT,


Ok I got your point. At the moment this is not possible in Looker. But I am happy to pass along your idea to our product team. Thank you for bringing this up.


Best,


Sasha

Userlevel 6
Badge

On a similar note…

why is there a link between the model file and the lookml dashboard (using the include), why isnt the link just 1 way (from the dashboard to the model file - especially seeing as each element in the lookml specifies which model it comes from)

The way it works now causes annoyances for us and even by default when you create a new model file it will “include: “*.dashboard.lookml”” which will end up creating lookml dashboards for any existing dashboards in that project for that model.

Hey again @IanT,


Auto Generation Of Multiple Models Can Duplicate Entities


When auto-generating a new model from a connection, the default model file uses this pattern:


OLD LOOKMLNEW LOOKML

include: “.dashboard"

include: "
.view”

When only one model is auto-generated into a project the syntax above works fine. However, if more than one model is auto-generated into a project, there can be some duplication. For example, if all dashboards are included in all models, those dashboards may appear to users more than once (once for each model). To avoid this, you can use more specific references in your models so that everything only appears once:


OLD LOOKMLNEW LOOKML

include: “overview.dashboard”

include: “inventory.dashboard”


This is how it is currently built/modelled in Looker. For more info please refer to here


Best,


Sasha

Userlevel 6
Badge

Yes this is what I understood/thought from the experience I have had so far with this.


Is there a reason why it needs to be linked/included. The referencing in my logic is that the dashboard is downstream of the model (as in I can understand why the model needs to include the dashboard, it doesn’t need anything from that file?).

Every element in the dashboard says which model its from so why is it needed to link a whole dashboard to a model?

Userlevel 3

@IanT, you do not need to set a model in every element definition on a lookml dashboard. If left unset it will default to the model where the dashboard resides.


For your use case, you could have one lookml dashboard with elements that do not set a model. Then you can include the dashboard in two models with different connections and this will create a copy of the dashboard for each model and you will only need to maintain the dashboard in one place.

Userlevel 6
Badge

perfect, thanks for your input rufus!

Hello. I realise this is a really old thread but I was wondering if a solution for that ended up being implemented.

Userlevel 6
Badge

Yes, as rufus said in his last comment. LookML dashboard with the model attribute remove for each element.

If the dash.lkml is included in a model then it will default to that model.

This will result in multiple dashboards but with only a single source.

If you want only 1 piece of content then you could make a parameter which selects the database (or gcp project) that changes the sql_table_namefor example.

Thanks for the update Ian. I guess this means you still have to define 2 different models which would duplicate the same information in order to use 2 different DB connections, right? Or have you found a way to get around this as well?

Our use case is currently similar to what I understand was your situation as well. We have DBs in 2 different environments which have the same structure but different data and want to have the same set of reports for both environments. So I’m wondering if we would have to duplicate the model (once for each environment) or whether there is some way to reuse that as well.

Userlevel 6
Badge

If it’s a different database host then I don’t know of a way of avoiding the 1:1 model:connection ratio, if it’s another schema or you are using big query for example you could parameterise the project in the project.dataset.tablename in each view.

Reply