Feature Request: pass key to should_cache_fn

[Acbarakat]

There are some instances where the should_cache_fn should return false based on key information. For example, when the key has some arguments in its string based on date and one does not wish to cache anything matching today and none of this data is in the data object.

[zzzeek]

is this in the context of the get_or_create() method or when using the decorator ?

[Acbarakat]

My specific content is wanting this feature when I use get_or_create_multi()

[zzzeek]

So there's not a really great way to add that because it would be backwards incompatible. can you do your key-based heuristic before you send the keys in ?

[Acbarakat]

That's the rub; you may not know which keys (if any) need to be cached until those keys are passed to the creator function. My inelegant workaround is to make a class, save the needs-to-be-cached keys to a class property and pop them in the should_cache_fn. Not very pretty and potentially inaccurate.

[zzzeek]

That's the rub; you may not know which keys (if any) need to be cached until those keys are passed to the creator function.

OK this is not making much sense what use case this could possibly be, you know the key up front, but that's not enough information to know if you can cache the value. the creator function gets the key, and then it generates a value. then afterwards, somehow the combination of the key and the value tells you if you want to cache the value or not.

why not just encode this "should be cached' information with the value you're returning? What is the information specifically ?

[zzzeek]

noting again, I dont immediately see a way to add this feature, unless we 1. do a python inspect() on the given function and decide it's among one of multiple calling styles, which I really don't like having to do that, or 2. we add entirely new arguments for these new functions. In both cases, entirely new flow has to be implemented and tested and carried along to all future APIs that refer to these methods, basically adding maintenance burden forever, but it's for a use case that is extremely unlikely to be generally useful, since so far it seems like it would be very simple to associate the "cachable" status with the value itself.