Content Validator with breaking dimension type changes



We’ve been having a lot of success with using the content validator as part of our deployment pipeline, but recently ran into a use case which I’m not sure the content validator supports.

For any dashboard or look that utilizes a dimension as part of the filter predicate, I’d expect a rename to be picked up by the content validator. However, what if the dimension’s type changes? For those existing dashboards and looks, would it be expected that they would show up as having invalid filter values given the dimension’s new type?

We ran into an example of this when we changed a yesno type to a string to allow multiple values. All the existing filters were expecting “Yes”/“No” which were no longer valid after the dimension change.

If this is not an accepted use case, are there any shortcuts or workarounds that don’t involve iterating through all looks and dashboards and manually checking those values? Thanks!

(Izzy) #2

Hmm, so I gave this a shot, and it looks like two things are happening:

  1. The content/filters are actually updating automatically, to change the filter type from yesno to string.
  2. A SQL error is being thrown, since the filter is now filtering on a number (my yesno was a number) and expecting “Yes” as the input, which isn’t accurate.

So, since the error is at the SQL level, and not a LookML model issue or anything, I doubt that the content validator would be able to be of much use here.

A solution could be to use i__looker to generate a list of all dashboards/looks that use that filter-- There’s a Query > Filters Used field that you could filter on to find all dashboards+looks that use that filter, and change them from there.

Let me know if that hits the mark!


Thanks for the quick response, Izzy. This confirms what we were suspecting.

I’ll definitely check out i__looker to see if leveraging that is easier than the method I was originally going to pursue to iterate through all dashboard and look definitions to check the filter expression used. I think between the two, we’ll be able to figure out a process to check for this scenario.

(Izzy) #5

Cool, glad to hear it. Definitely come back and let everyone know what your final process looks like-- Sounds like it could be helpful for others in the future.

(Luke Brutvan) #6

Quinn also wrote this useful API based approach