Hiya - is this the best way to do this? I can see issues arising when people reuse the _cache_key incorrectly. Wouldn't it be better just to make a SHA1 of the filter, and use that as a unique ID?

@clintongormley People will always make mistakes..., it does not mean we should not expose features because of that. The downside of using SHA1 / MD5 on the data is the cost that comes with calculating it. Not saying that we shouldn't do it, possibly even trying to guess the size vs. cost automatically, but there should be an option for people to provide the cache key.

@kimchy My question is: what functional purpose exists for exposing this in the API?

All people care about is whether a filter is cached or not, they shouldn't care what name you use to cache the filter internally.

Re cost, you could just say: if length $cache_id > $max, then $cache_id = sha1($cache_id), so you'll be hashing the minority of cached filters

All people care about is whether a filter is cached or not, they shouldn't care what name you use to cache the filter internally.

Now :), there are more things that will happen down the road where this makes sense. Just a simple sample is invalidating specific filters based on cache key patterns. Other as well, though, its too early to really (nothing baked) to write about...

Re cost, you could just say: if length $cache_id > $max, then $cache_id = sha1($cache_id), so you'll be hashing the minority of cached filters

Agreed, thats what I meant by doing size vs. cost. As to the fact that its a minority or not, it really depends on the app..., so you want to allow them to control it. This size vs. cost thingy can actually be the default for something like terms filter (the obvious heavy one), maybe open an issue for it?

Opened: #1146