Lookml Code "Warranty"? Anyone ever been advised that their was a warranty on Lookml?

[pmccabe]

Just off a call with Looker, and we were advised that after 7.8 broke our existing lookml model that nothing could be done by looker as lookml has a “warranty” and we’re out of that apparently? We had been advised to use a feature in the early days quite heavily, however, it turns out that feature supposedly was a “bug” that we had been taking advantage of (despite being advised to set up this way by looker). Anyone had similar experiences?
We now have a lot of development work, without any warning to fix this issue.

[mprogano]

What’s the feature / bug code?

[pmccabe]

We use html links in a dimension to print pdfs, link to other dashboards etc. that pull in filters using the liquid “_filters” syntax. We would use one piece of code in the common model and then use this across multiple dashboards, explores, and client models and list all the filters that could be called into the html link. If we used the link on an explore where some of the “_filters” where not linked at the model level, then the code and linked still worked and there were no issues. Now since looker has started checking liquid syntax for “_filters” we get an error. Even 6 months ago, i was working on a new link and this was suggested by looker and now I’m being advised our whole model and set up is no longer in “warranty” so they won’t help.

[mprogano]

What’s the “right” way to write it? What’s the two codes look like side by side?

[izzymiller]

This post has been edited for accuracy. Feel free to look at edit revisions if you’re curious about what changed.

Hey Peter,

I think there’s a few points of confusion here that I’d be happy to clear up.

First, definitely a bummer that there is now extra development work to do and annoying warnings. I’m sorry about that and we would never intentionally cause something like this to happen with no warning. It was one of those unforeseen impacts that we are always working to catch prior to release. This one was a miss, and we apologize.

The warnings

Regarding the actual issue, which it sounds like is the ‘Expected value in “_filters” to be a field name’ warning, the functionality you were relying on should still be ok, I believe, so long as you are not using _filters[] in SQL. It sounds like you are just using it in html, but for clarity’s sake, it’s never been recommended to use _filters[] in sql.

The “bug” in this case was the validator not working properly on liquid, meaning there were many occasions where _filters[] was used with an improperly referenced field in it, ie: _filters['this_field.does_not_exist]. That would have never thrown an error previously, but as of 7.8 began throwing a warning. The actual functionality did not change, just to be super clear.

You can reduce the code quality settings in the project temporarily (in the project settings) to allow you to continue developing in the meantime.

In 7.10, we improved these warning messages to make it easier to troubleshoot and they now reference the offending line number instead of being totally opaque. In 7.14, about to release, we’ve added the offending field name as well to make it even easier to fix.

I recommend updating so that you can take advantage of the improved error messages which should make resolving the problems not too bad.
If you can’t update, I’m sorry to say that it is a bit of a painfully manual process to resolve these:

1. Search in IDE for which views are using _filter[] in a url
2. Jot down the view names & fields that are being referenced in those _filter[]
3. Go to each model and explore listed in the warning and see if they’re using any of the views
4. If so, see if they’re missing any of the views that the fields in _filter[] use
5. Repeat as necessary until warnings are resolved

So that’s the actual issue at hand.

The warranty

Regarding the warranty, I’m concerned this might cause a bit of broader misunderstanding. To be clear, LookML you have written does not come with any kind of warranty or expirations, though we do sometimes deprecate features per our legacy feature deprecation schedule, which will always include ample warning many versions in advance. We are always happy to support you with any Looker issues, so even if you come to us running Looker v1.5 and old LookML, we will certainly help you out to the best of our ability. However, professional services engagements and the code written therein do come with a standard 30 day warranty period— Your specific engagement may be subject to different terms, but it’s standard practice to have a “warranty” on the actual work done by Looker.

The situation I’m assuming happened is that our Professional Services team completed some work for you/made some recommendations during a SOW several years ago, during which this code was written, and that project is now past its end date so is fully closed and the “Warranty” has expired. We are now well outside of the SOW so any new professional services work would need to be under a new engagement. If there are some specific issues in the customer experience of this, that’s awesome feedback that we’d love to hear.

The fastest way to get deploying code again (i imagine this is your primary urgent concern) will be turning off code quality restrictions for now. I definitely recommend updating to 7.10 now and 7.14 when available for the easiest resolution of the warnings.

Lastly: I think this forum is no longer the best place for the rest of this discussion, since it’s very specifically related to past engagements you’ve had with Looker and your LookML. I’ve been looped into a few internal discussions and the members of your success team are all well apprised of the situation and working to resolve it, so it’d be most efficient to continue to work with them (Unless you’d rather keep talking to me instead, in which case I’m here all day 🙂).