Feature Request: Cache invalidation / hash change on decorated function code change

[jmrichardson]

Hi, I was wondering if it's possible to include the function code in the cache? That is, if I make a change to the function code, the function will not serve from cache. Thanks for any advice.

[shaypal5]

Hey.

Please see my comments on your PR, #35 .

[jmrichardson]

No Worries, it was just a quick way to add source code to the hash function. Unfortunately (and this is not a dig because cachier is a very nice package), cachier doesn't seem to work with class functions. This is a big use case for me and really don't have a deep understanding of cachier for the enhancement. Maybe you would consider adding the enhancement? :)

[RolfsWeather]

I would also like this feature. Personally, I would prefer it to default-on (with configuration to turn it off), because that seems like the most sensible situation to me. If you change the code in your function, then obviously it is going to change some of the results; and if those results are already persisted, then you are going to get incorrect results.

I understand the concerns about whitespace or comment/documentation changes; but that sounds like an optimization to me.

I really like this project, but the first time I used it for anything interesting, I found myself renaming my function a half-dozen times to force the cache to reset after fixing some obvious bugs in the function. I ended up writing a manual wrapper function to preserve the external interface.

Although, I should point out that hashing the source code is not a perfect solution: if it calls other functions that have changed, then it will not reset the cache. To be pedantic, it would be nice to have an option to pass a list of called functions to the decorator, which will all be added to the hash for the source code. It might be error prone, but it at least gives the ability to handle these types of changes.

[shaypal5]

1. You can manually reset the cache. See here: https://github.com/shaypal5/cachier#id6

2. The main concern is indeed cascade of changes from inner function calls, which is extremely common.

Still, I agree it's a great feature. It just requires some real work and extensive testing for edge cases, so someone has to pitch in, or I'll just get to it if enough people nag me about it and I get some time. :)

[shaypal5]

Also, note that any change will have to overcome the problem discovered in #35 , which forced a version rollback.

[shaypal5]

Just leaving here an updates status:

This is an often-requested feature which is way more complex than it seems initially.

This was discussed in the following issues:
#9
#34
#70

And attempted in two separate pull requests:
#17 , which was merged and then had to be reverted due to issues #18 and #19
#35 , which was rejected for the same reasons.

I would absolutely LOVE it if someone would like to make a contribution to help with this feature. Any such potential contributor, however, would have to start with getting up-to-date with past discussions, issues and attempted contributions.

Please continue all related discussion there.

Cheers,
Shay