-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add clarification about expiration of items #1262
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on existing text, it could be considered either a clarification or an errata (that requires a vote).
Either way, @Crell is the editor and final authority here.
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. |
Agree. |
Agree as well. |
Agree. Marking the errata in the meta document is what makes it possible. |
+1 from me |
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 |
See symfony/symfony#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.