Same dashboard/looks on different connections

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:

• Parameterize connections with user attribute (link to Discourse)



• Or as you mentioned, you could use multiple model files in the same project and change the connection parameter (link to Discourse example)

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

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

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

@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.

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

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.

Would work great for embedded use cases but not so much in the Looker browser UI.

TL;DR: Copying a LookML dashboard into sub-folders (as per the Looker Access Docs) will convert it to a user-defined dashboard, breaking the version-control and override the blank model: param in the .dashboard file. 

Long Version:

We have customers, which fall into three ‘customer categories’ aka Groups. Our data/content is sometimes exactly the same across the customer types. But sometimes, it is highly sensitive and we don’t want the risk of exposing some data to a customer-type who shouldn’t see it.

So, for security purposes, we’re thinking of creating one model per customer type. We create base explores in the one project and include them in each model as needed. Then, we can create a single version-controlled LookML dashboard built from base explores.

However, organizing this in folders gets problematic. We don’t want to expose all content to each of our customer-types because that would be confusing, so we created folders specific to each customer-type and assigned it to each customer-type group.

But here’s the problem: the LookML dashboards live outside of these model-specific folders.

Some Options

Copy LookML dashboards from LookML folder into the customer-type folders...but that breaks the version control linkage.

We could instruct our users to view the LookML dashboards folder outside of their specific customer-type folder...but you can’t organize that folder further, so it will just be a super-long list of dashboards (not great for user workflow, also, what about saved Looks?? Those are going to be in their customer-type folder...)

Very unfortunate snag...any thoughts here? I feel like it would look like this but there doesn’t seem to be a connect between the models and the folder structure….

Perhaps we need to think about the models more like business functions and then assign the customer-types those models in a set?