Creating stable look urls for multi-environment framework

[_Noah]

Hi all,

We’re looking to create a multistage environment for our company to help with hardening our environment. The question that comes up for us is how do we get Looker objects shared between environments be able to readily identify them (both as a user and an automated service). The incremental ID used for dashboards and looks will inevitably have collisions and cause issues.

We preferably want to be able to “sync” objects (Looks and Dashboards) between the environments at will. Looker’s inability to allow us to safely test Looks and Dashboards without “publishing” the change makes the environment synchronizing an important addition to take our team’s Looker development to the next level.

As @davids mentioned here dashboards can use a slug instead of incremental ID. This solves our dashboard issue but unfortunately Looks don’t currently allow this…

Since we are not hosting our Looker instance the only other solution I can now think of is maintaining a separate service that is a “look link resolver” that owns a database that links one Look ID in one environment to another Look ID.  This is obviously not preferred as it leans too far into the category of “over-engineered” for my liking (considering a separate web service would be required to be maintained for a single function).

Does anybody have any other ideas that would allow us to sync Looks between environments?

[IanT]

We do exactly as you said, we have an api service that returns the synced id. When we sync we put the original id in the title of the content for manual purposes (easy to search out).

A year+ ago it looked like Looker were starting to phase out looks. It’s not possible I don’t think to restrict people from creating looks but that would be a way to avoid this issue.

[_Noah]

Thanks for your reply @IanT . Disheartening to hear that others have to go so far to come up with a solution. But I suppose it’s good to know there is some work-around that is in use today.