fig-standards
fig-standards copied to clipboard
php-fig
Add clarification about expiration of items
See https://github.com/symfony/symfony/issues/44995 for details. The spec isn't extremely clear about this but all implementations I checked (very reasonably) do this already. It does not hurt to spell out the "obvious" IMO as it may not be obvious to everyone.
I am not sure if this belongs here or rather in a ML post, but anyway this is a starting point for a discussion.
Hrm. I think the original logic from the spec authors was along the lines of "all cache writes are independent of each other. The existence of a previous record is irrelevant, it gets overwritten entirely." "Entirely" means "including its TTL." So of course load/save like that would result in a new TTL being set. I think that is still the correct behavior; A cache is not a database.
Editing the spec text directly is a no-go. But we can include an Errata that clarifies the above reasoning and specifically recommends that implementations always treat a cache write as a full-overwrite, and not persist a TTL.
The thing is all implementations I checked appear to do it correctly. What needs fixing is the user documentation to ensure people don't have the wrong expectations and try reusing / updating a cached item.
So maybe the wording can be improved, but IMO it makes a lot more sense to update the docblock with a clarification for users than an errata virtually no user will ever look at.
I think we can update the docblock in the actual package. We've tweaked those as part of the type updates before. I am not sure if updating the spec proper is kosher. However, I'm open to input from other CC members.
Ah yes an errata in spec and then a docblock patch in the spec would be totally fine for me too.
an errata in spec and then a docblock patch in the spec would be totally fine for me too.
Agree.
Just to make sure that we are all talking about the same thing: The proposal is to add errata and documentation to clarify that TTL might not be set when retrieving a CacheItemInterface object from a CachePool and that when 'updating' a cache item it is the responsibility of the user to set a new TTL?
Yes, add errata and update at least the docblocks in the psr/cache repo, if the docblocks in the spec cannot be updated due to red tape. Exact wording is TBD as far as I am concerned, I just thought it'd be good to highlight the fact that yes TTL might not be set (probably SHOULD not be set) on a CacheItemInterface object retrieved from the cache, and that on save() a previously stored item with the same key will be overwritten completely, inclusive TTL.