Disable all caching

[banesullivan]

There are use cases for local computation where caching isn't desired. Caching is excellent for stateless environments where multiple users may be requesting tiles/thumbnails of the same image repeatedly or even in local environments when dealing with non-pre-tiled datasets. However, caching introduces unexpected results and stale data in local, stateful environments (like me as a single user in a Jupyter Notebook).

For example, I want to experiment with an algorithm to interactively to produce a new raster and call it "ndvi.tif". I want to toy with the algorithm: tinker with the computation, re-run, overwriting the existing data, and visualize the result with large_image to see how my changes to the algorithm affected the result.

This scenario wouldn't be a problem if I set up some temporary file mechanism to save a new temp file for every computation, and in effect have large_image open a new file on each iteration. But I don't want to do this. I don't want to save tons of new files. I want one working file.

The trouble is, large_image caches the tile source, and this workflow isn't possible.

To simplify the testing of this, I have two versions of the same image, ndvi-09.tif and ndvi-11.tif, which I will save as ndvi.tif and attempt to reload with large_image

ndvi-09.tif	ndvi-11.tif

The solution given in #985 isn't sufficient as there is still some caching going on that prevents large-image from re-opening the same path as a new tile source

import large_image
large_image.config.setConfig("cache_tilesource_maximum", 1)
large_image.config.setConfig("cache_python_memory_portion", 1_000_000_000)

!rm ndvi.tif
!cp ndvi-09.tif ndvi.tif

large_image.open('ndvi.tif')

!rm ndvi.tif
!cp ndvi-11.tif ndvi.tif

large_image.open('ndvi.tif')

Uh oh! That thumbnail above isn't right! It's using the cached tile source even though restricted the cache constraints.

[banesullivan]

I'm wondering if it would be easiest to implement a "dummy cache" that always misses that users can opt in to

[manthey]

Here is a hacky way to do it:
Immediately after importing large_image, do large_image.cache_util.cache.LruCacheMetaclass.__call__ = lambda x, *a, **b: large_image.cache_util.cachesClear() or type.__call__(x, *a, **b)
This disables the tile source cache AND clears the tile cache whenever a new tile source is created. We probably don't want to get rid of the tile cache entirely (but I could be wrong), as then asking for a thumbnail and then tiles would be less performant. But, since reopening a file that is now different still results in the same cache keys for tiles, we need to either have a cache keys that are more dependent on file properties (or maybe use a uuid4 for the source) or flush the tile cache for that file; we don't expose any way to flush the tile cache on a per-file basis, so flushing the entire tile cache is a balance.

[manthey]

A better hack is probably:
large_image.cache_util.cache.LruCacheMetaclass.__setitem__ = lambda *a, **b: large_image.cache_util.cachesClear() as it doesn't break pickling sources

[manthey]

A better hack is probably: large_image.cache_util.cache.LruCacheMetaclass.__setitem__ = lambda *a, **b: large_image.cache_util.cachesClear() as it doesn't break pickling sources

Actually, this won't work right -- we'd have to override the __setitem__ of the cache, not the cache metaclass.

[banesullivan]

The first approach fixes the problem for me!

[manthey]

It will break pickling the tile source, so we still might want to define a config value to do this more correctly.

[manthey]

When #1296 is merged, this can be accomplished with a config setting. This will NOT break pickling the tile source.