You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@superset.apache.org by GitBox <gi...@apache.org> on 2017/11/12 05:00:10 UTC

[GitHub] john-bodley opened a new issue #3840: The cache key for /warm_up_cache/ differs from /explore_json/

john-bodley opened a new issue #3840: The cache key for /warm_up_cache/ differs from /explore_json/
URL: https://github.com/apache/incubator-superset/issues/3840
 
 
   Make sure these boxes are checked before submitting your issue - thank you!
   
   - [x] I have checked the superset logs for python stacktraces and included it here as text if any
   - [x] I have reproduced the issue with at least the latest released version of superset
   - [ ] I have checked the issue tracker for the same issue and I haven't found one similar
   
   ### Superset version
   0.21.0dev
   
   ### Expected results
   Both the `/warm_up_cache/` and `/explore_json/` API endpoints should produce the same cache key for a given slice. A hashed version of form-data is used for the cache key, though it seems the AJAX form-data is mutated via i) the JavaScript and ii) via the `Superset.explore_json(...)` method thus the keys are not equivalent. 
   
   ### Actual results
   Using the example dataset, the `/warm_up_cache/?slice_id=60` endpoint hashes the following string for the cache key: 
   
   `[(u'compare_lag', u'10'), (u'compare_suffix', u'o10Y'), (u'granularity', u'ds'), (u'groupby', []), (u'json', u'false'), (u'limit', u'100'), (u'markup_type', u'markdown'), (u'metric', u'sum__num'), (u'metrics', [u'sum__num']), (u'rotation', u'square'), (u'row_limit', 50000), (u'series', u'name'), (u'since', u'100 years ago'), (u'size_from', u'10'), (u'size_to', u'70'), (u'slice_id', 60), (u'slice_name', u'Name Cloud'), (u'until', u'now'), (u'viz_type', u'word_cloud'), (u'where', u'')]`
   
   whereas `/slice/60/` endpoint hashes the following string for the cache key:
   
   `[(u'color_scheme', u'bnbColors'), (u'datasource', u'3__table'), (u'filters', []), (u'granularity_sqla', u'ds'), (u'having', u''), (u'limit', u'100'), (u'metric', u'sum__num'), (u'rotation', u'square'), (u'series', u'name'), (u'since', u'100 years ago'), (u'size_from', u'10'), (u'size_to', u'70'), (u'slice_id', 60), (u'time_grain_sqla', u'Time Column'), (u'until', u'now'), (u'viz_type', u'word_cloud'), (u'where', u'')]`
    
   I'm not sure what the correct way to proceed is. I presume there are a couple of options:
   1. Update the cache key logic to contain a whitelist of form-data fields to hash. Note this may be difficult to maintain.
   2. Deprecate the `/warm_up_cache/` API endpoint and augment existing non-API endpoints to pass the `force` request argument, i.e., `/slice/60/?force=true`. Note the issue with this approach is one may need to use a headless browser if the intent is to systematically warm up the cache. 
   
   ### Steps to reproduce
   See above.
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services