-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Cache] Add CacheItem::validateKey utility method #18597
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -99,6 +99,30 @@ public function expiresAfter($time) | |
return $this; | ||
} | ||
|
||
/** | ||
* Validates a cache key according to PSR-6. | ||
* | ||
* @param string $key The key to validate. | ||
* | ||
* @return string $key if it is valid. | ||
* | ||
* @throws InvalidArgumentException When $key is not valid. | ||
*/ | ||
public static function validateKey($key) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we can refactor this into There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. returning a boolean would mean that it should not throw the exception either, which would complicate things a lot (especially to give the right error message). So this looks like a bad idea to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand this comment. We can return a boolean and throw exceptions. Some Symfony methods already do that. Anyway, maybe the problem is with the method name, because it's not a validator but a normalizer (in theory it could change the value of the key to make it valid). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A normalizer would transform its argument, here the argument is only checked against a set of rules and never modified. To me, it validates... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I understand a validator as something that returns true/false depending whether the value is valid or not. But here we are throwing exceptions and returning the original value (potentially modified). To me it's very confusing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's exactly the helper that PSR-6 implementations require, only that. Not some sort of architectural master piece...
Never! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
In theory. But since we return the value, we could modify it unawarely (10 minutes ago you fixed a similar problem: #18603). This couldn't happen with a proper true/false validator. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is very well tested. Try changing it and everything will go red, really. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @javiereguiluz but your suggestion of a true/false validator is precisely what makes things much harder to use: when receiving false, you cannot know what is the reason, and so you cannot put a meaningful message in your exception. And if you keep throwing inside the validator, it is not a true/false one anymore but a true/Exception one (with a name There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See #18604 |
||
{ | ||
if (!is_string($key)) { | ||
throw new InvalidArgumentException(sprintf('Cache key must be string, "%s" given', is_object($key) ? get_class($key) : gettype($key))); | ||
} | ||
if (!isset($key[0])) { | ||
throw new InvalidArgumentException('Cache key length must be greater than zero'); | ||
} | ||
if (isset($key[strcspn($key, '{}()/\@:')])) { | ||
throw new InvalidArgumentException('Cache key contains reserved characters {}()/\@:'); | ||
} | ||
|
||
return $key; | ||
} | ||
|
||
/** | ||
* Internal logging helper. | ||
* | ||
|
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.
Sorry for adding comments in a merged PR, but this was merged a bit quickly. I have some concerns about how
validateKey()
is used. It's a validator, but it's used like a getter or a normalizer.Instead of this:
Why not using it like this?
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.
This would just raise the boilerplate, whereas the current behavior keep it low IMHO.