@cache_multi_on_arguments does not respect cache expiration time #128
Comments
Michael Bayer (zzzeek) wrote: can you share evidence for this? haven't had time to look but the tests should be covering this (perhaps they are not). |
Michael Bayer (zzzeek) wrote: the issue I can see here would only impact when an explicit call to invalidate(hard=True) is involved. will be fixed momentarily. |
Michael Bayer (zzzeek) wrote: it should usually be raising a TypeError since most kinds of objects aren't comparable to the timestamp number. |
Michael Bayer (zzzeek) wrote: https://gerrit.sqlalchemy.org/#/c/zzzeek/dogpile.cache/+/830/ |
Steven James () wrote: I can try to work up a minimal example or some test code if you'd like... The value returned by the 'v' key appears to be a number also (0 or 1) so I'm not sure it would raise a TypeError. (Your linked patch does fix the problem) |
Michael Bayer (zzzeek) wrote: i would gather you're caching integer values for it to be not failing. the test suite is doing the same thing which is partially why they didn't show this problem. |
Michael Bayer (zzzeek) wrote: Use correct element when checking hard invalidated Fixed issue in the :meth: Change-Id: Ibc08ec153a4c05d070661278b64695000cff4cef → 8e9d965 |
Changes by Michael Bayer (zzzeek):
|
Steven James () wrote: I think it was trying to look up a mutex value for each key. Once it got the 0/1, it went ahead and determined that the value for that key needed refreshing. Once I saw the 'v' instead of 'ct' there and looked into the change history I stopped looking further. Thanks for resolving this so quickly! |
Michael Bayer (zzzeek) wrote: 0.6.7 is released |
Migrated issue, originally created by Steven James ()
Any function decorated with @cache_multi_on_arguments calls its refresh function on every call, even if the expiration time is set very long.
The text was updated successfully, but these errors were encountered: