[CCACHE-25] TTLCache appears to have inconsistent behavior with respect to the TTL parameter Created: 02/Aug/12 Updated: 14/Aug/12 Resolved: 14/Aug/12
There appears to be some inconsistency in the implementation of TTLCache. Specifically, it appears that if you lookup a value whose TTL has expired, but no new items have been added to the cache, it will still be present. But if you ask if the cache has? the value, it will report that it does not. For example:
So here we see, has? reports the value is no longer in the cache, but get will still give you the value. Unless I am misunderstanding the purpose or contract of these two functions, it seems that they should agree in whether or not a value is in the cache.
This also brings up the question of whether a value in a TTL cache that has passed the TTL should remain in the cache until the cache is updated. My expectation was that an item is not in the cache after the TTL has passed (ie, has? is currently correct). I can also see the argument that the TTL parameter is merely a lower bound on the amount of time it is cached; if it can be accommodated for longer, it will be (and thus lookup is currently correct).
As I said, my expectation was that things are no longer in the cache after the TTL, and I would still vote for this behavior as the correct one for a TTL cache, as it seems like a reasonable cache to use for things that can change out from under you, but a short period where it is out of date is acceptable (which is how I was trying to use it).
|Comment by David Santiago [ 14/Aug/12 6:39 PM ]|
core.cache 0.6.2 fixes this issue for me; the call to get in the code above now returns 'nil' to match the false return from has?. I'd close the issue if I could.
|Comment by Fogus [ 14/Aug/12 8:33 PM ]|
Fixed in v0.6.2