Looker Connect Training

Help Center

Documentation

Community

Cloud Certifications

Question

Cache seems to not work using pre-defined Look, User Attributes, and API 3.0

  • 29 November 2017
  • 3 replies
  • 299 views
W

I am able to call Looker’s 3.0 API with a user_attribute. It’s really neat, I can take some user_attribute like user_id or some_arbitrary_field from my own system, and pass it to my pre-defined Look so that it filters on that specific data. 👍


My implementation for that is currently based on this article. Based on that article, I understand that this is the process for passing a user_attribute to a pre-defined Look via the API.



  1. Get the Look, specifically, the query from the pre-defined Look


  2. Run an inline Query using the query body above, but with my user attribute(s) plugged in


The query runs great, but the ?cache=true query parameter does not seem to be taking effect. I cannot tell if the caching period is not working properly, if my invocation is wrong, or what is causing the cache parameter to not be effective.


My query takes several seconds every time it runs.


If I do ?cache_only=true, then the query is cached and takes less than 1s every time, but I do not know if that’s the behavior I want.


The docs state that cache will “Get results from cache if available.”


And that cache_only will “Retrieve any results from cache even if the results have expired.”


I guess my questions are as follows.



  1. Is my implementation wrong? Should I be doing this another way?

  2. Why doesn’t cache=true ever seem to be using cached data?

  3. Where in the Looker Admin UI can i see/modify the cache time for my Look?

3 replies

paola
Rank
Userlevel 3

Hey @williamhaley,


I tried reproducing the behavior you’re seeing internally but I am getting data from cache when specifying ?cache=true.

By default, Looker will cache queries for 1 hour. However, this cache period can be increased or decreased at the model or explore level using the persist_for parameter. I would suggest checking the model and the explore that this Look is built off of to confirm that there is, or isn’t, a persist_for parameter defined.


If you have Admin privileges, you could also query the i__looker History explore to confirm whether your data is pulling from cache or not. There is a source field that we can filter on to display queries coming from API 3.0 and a result source field that will show if the query comes from cache.

An example query you can use for this is:


https://[yourdomain].com/explore/i__looker/history?fields=history.created_time,history.source,history.result_source

&f[history.created_time]=today&f[history.source]=API+3.0&sorts=history.created_time+desc&limit=500&query_timezone=UTC

Just replace [yourdomain] with the appropriate domain for your Looker instance. Hope this helps!

W

Thanks @paola!


I checked out the i__looker History explore (I am an Admin, and that’s a handy query to bookmark). It looks like my inline queries are indeed failing to use their cache.



My URL to run the query is formed like this. queries/run/html?cache=true&cache_only=true


I tacked on both cache and cache_only, but for some reason neither seems to be working now.


I navigated to my Look via the web UI and clicked explore from here to access the explore.


I may just be missing it, but I do not see any settings or options that seem related to setting a persist_for field on the explore.


I also looked at my model in the web UI, but again I cannot find any place where I may be able to set the persist_for field.


Is persist_for only settable via the API? Which API should I use to look at the details for my model and explore? I cannot find any top-level APIs that seem related to explores. I looked at the docs for LookerML models, but I do not see any mention of the persist_for field there either.

paola
Rank
Userlevel 3

Hey @williamhaley,


Glad to hear that link was helpful! It’s definitely strange and unexpected that the queries aren’t pulling from cache, if cache is available. I’d love to take a closer look at the queries you are running, the calls being made, etc. If you could visit help.looker.com with that information, we can take a closer look at the issue.


In regards to the persist_for parameter, this is defined at the explore or model level within a LookML project. This is not currently set via the API.

Reply


Terms of Service