Purpose of tags if not for search?

[deeplook]

I've stumbled over this exciting project! Congrats!

Looking at tags I thought they might be very useful for searching items, but I don't see how that would work. And hence, what their intended purpose is right now? Also there is a statement in #118 that search in not a goal for this project. I understand that adding saerch feature would make DiskCache look more like a real database, though.

[grantjenks]

The tags mainly support eviction: http://www.grantjenks.com/docs/diskcache/api.html#diskcache.Cache.evict

For example, I used them once when doing dynamic image resizing on the server. The client could request an image of a particular size and the server would grab the image from a blob store and then resize it and cache the resized image. When the resized image was cached, it would use a key like "image-1234-size-1024-by-768" and include "image-1234" in the tag. Later if the client uploaded a new image and replaced "image-1234" then I would evict all items with tag "image-1234" from the cache.

Tags can also be simple metadata (they don't have to be strings). When retrieving a tag via get() you can request the tag too. I used that once for an expensive API call. I didn't want to change the key or value but I wanted to include some metadata to record how long the item took to generate. I stored that information as a float in the tag.

[deeplook]

Makes sense. And having arbitrary tags is cool, but would make using them for search not exactly easier. But I still think it would be helpful to have an analog operation to cache.iterkeys() but over the tag values only, like cache.itertags() so you could walk efficiently over these tags and decide dynamically what to really get/fetch from the cache.

[grantjenks]

Maybe but I don’t see a compelling use case. Seems easy to use iterkeys() and get() as a start.

[deeplook]

iterkeys() returns only keys, but no tags, and to get the tags you must get the entire item from the cache. Which one could avoid if there was a way to get the tags only.

[grantjenks]

That’s a good point. What’s your use case?

[deeplook]

I'm mostly interested in searching and ordering for keys, or alternatively for tags. When you work with geohashes e.g. you want to access a hash "next to" another one in your cache. https://github.com/litl/park e.g. has lexical traversal of keys.

[grantjenks]

I see. That’s helpful. So you’d like to do bounds/prefix queries on both the keys and tags? It seems possible given the indexes are there. But the API for that functionality is not obvious to me.

Maybe like:

irange_keys(lo=None, hi=None, inclusive=(True, True), keys=True, values=False, tags=False)

irange_tags(lo=None, hi=None, inclusive=(True, True), keys=True, values=False, tags=False)

The “prefix” case looks special for strings. I’m not sure it should be included.

[grantjenks]

It might also make sense to have two separate caches: key-value and key-tag.