On 08/08/2016 11:26 AM, Nicolas Grekas wrote:
Hi
sorry to come late in the story. I'm the author of the PSR-6
implementation in Symfony Cache 3.1.
Greetings!
I'm going to only reply to the second half for the moment, as it's new
stuff. I'll let someone else chime in on the DateTime error handling first.
As promised, here is my list of grey zones in PSR-6, with the behavior
implemented in Symfony in brackets:
- What happens when one provides an unserializable value to save?
($pool->save/commit() returns false. Note the difference with the
previous issue: CacheItemInterface throws, CacheItemPoolInterface does
not throw, that's the rule I inferred.)
Return false, save nothing, and get a cache miss as a result later. I
believe that's the correct behavior per spec.
- What happens when one of several values can't be saved? (the
serializable ones are saved, the others ignored and
$pool->save/commit() returns false)
That seems like a reasonable solution. Save what you can, don't save
the rest.
- What happens when a value cannot be *un*serialized? (return a miss)
Should we allow a __PHP_Incomplete_Class? (no)
If a complete and valid value cannot be returned in a type-safe manner
for any reason, it's a cache miss. I'd say you're correct per spec.
- What happens when an already expired or negative lifetime item is
saved? (invalidate any existing value & return true)
I'd say this is correct. Technically, I believe the spec would say you
can save it and thus it will be a miss when it's next read, but since
you know up front it's guaranteed to be a miss not saving it at all
seems like a valid optimization. You're correct per spec.
- Are deferred items subject to expiration? (yes)
Yes.
- Is getting a deferred item a hit? (yes)
Yes.
- Are deferred items commited atomically? (no)
That is unspecified, so I guess either is legal? The intent for
deferred items was to allow for multi-set operations, or transactions on
an SQL DB. Some of those will result in a multi-value atomic operation
anyway. Since the spec doesn't specify, however, I'd say it's
unspecified. (I don't know if we can practically require one way or
another.)
- Should we store a `null` value for items that were a "miss" but have
no value set? (yes)
If a CacheItem represents a cache miss, $item->get() MUST return null,
per spec. How you do that internally is up to you.
- Should committed item objects have isHit() === true after being
saved? (no: not when miss at the origin)
Saving a cache item should probably be considered a destructive
operation on the object. Honestly I could see an argument either way here.
- What's the rationale for having reserved characters in keys, and why
these ones specifically? (no idea)
Reserved for usage in future extensions, like namespacing or tags. Those
seemed like the most likely ones we'd want to use.
Given that we already managed to answer all those questions while
implementing the spec, I hope we didn't make any mistake in
interpreting the PSR. Please tell me if we did anything wrong here.
It looks like you got it nearly all right, except for places where the
spec doesn't specify either way. :-)
For future implementers, it could maybe help to make some of these
points less implicit and more explicit? I'll let you cherry-pick :)
Thoughts on which ones? Most of them seem (to me at least) fairly
straightforward reads of the spec, and since you got them all right...
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/7467cc62-0776-abb2-7352-ea94f8cd885a%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
