Clean the caching suspension mechanism

[jwoillez]

At the moment there are two ways of preventing caching:

• Pass cache=True to BaseQuery._request()
• Use of the context guard with suspend_cache()
  We should settle for one solution only.

I like suspend_cache() as you can suspend the cache for large sections where multiple requests can be present. As long as suspend_cache() counts the number of stacked suspension, you should be able to properly suspend_cache() within a section of code where suspend_cache() already apply.

Thoughts?

[keflavich]

I prefer keyword passing in part because it doesn't require importing an additional function; my typical use of astroquery is something like:

from astroquery.module import Module
result = Module.query(something)

and I mostly do this interactively so that an extra line of import results in extra overhead.

There are also queries that could be cached but should not by default. There are some staging requests that should default to being cache-free, and I like seeing that spelled out explicitly.

I've never really run into the use case you mention; are you often suspending for whole sessions or scripts?

Also, it looks like downloads are not presently cached; I think they should be.

[jwoillez]

I see caching suspension as a developer concern only. Caching should be completely transparent to the user. Except maybe for a cache purge. I would always follow the use case you describe.

[keflavich]

@jwoillez - perhaps I'm missing something, but I think there are cases where the user might want to suspend caching, e.g. a query for which the user expects more to be returned because more data has been added to the archive. In this case, the user would have to use suspend_cache if we didn't have keywords, right?

Are you perhaps advocating that suspend_cache should be used in the source code, then? e.g.:

if not cache:
    with suspend_cache():
         do_operation()
else:
    do_operation()

that seems clunky but there's probably a better way to do that.

[it is late; please excuse me if I'm being entirely daft]

[jwoillez]

I see your point. Then what about adding a configurable auto-expiration of the cache? Then you would never have to worry about zapping it. It would be completely transparent. And for those who are not satisfied with this we could disable the cache at the module level or astroquery level. We could also provide a cache zapping method.

[keflavich]

Auto-expiration is a good idea. A configuration item is also a good idea. Cache-zapping is essential (see #417). Lots of to-do items here.

[bsipocz]

After the merge of #1634 I think this is now obsolete, but do reopen it if you think otherwise.