-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[PropertyInfo] Cache support #16917
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
[PropertyInfo] Cache support #16917
Conversation
22c5ede
to
3d15937
Compare
3d7efb2
to
677b45d
Compare
{ | ||
$this->listExtractors = $listExtractors; | ||
$this->typeExtractors = $typeExtractors; | ||
$this->descriptionExtractors = $descriptionExtractors; | ||
$this->accessExtractors = $accessExtractors; | ||
$this->cache = $cache; |
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.
instead of passing the cache here I would prefer using composition instead which decorate the default PropertyInfoExtractor something like https://gist.github.com/aitboudad/12419c2db6d19320c5fa
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.
same thing for #16838
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.
👍
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.
I was thinking the same thing initially, but finally I'm not sure that it's a good idea:
- Performance (and cache) is not an "optional" feature. It should be enable for all implementations in prod and IMO it's why it belongs to this class.
- In the context of the Standard Edition it adds a lot of complexity and an overhead: it requires to use the service decorator feature to switch the class depending of the environment (the cache must be enabled in prod, but not in dev)
- In the context of the component, it makes it harder to enable the cache (one more class to instantiate)
- all other components using cache doesn't use composition for that (it is considered as a builtin feature)
When the PSR-6 will be ready, the argument can even be made mandatory (it's better to always use a cache) and a NullCache
or something like that can be added for the dev environment (like with the Logger).
What do you think @symfony/deciders?
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.
👍 Composition is much cleaner and should be used unless it is not possible, like with the property accessor cache.
Switched to an implementation to a Decorator as requested. Should the decorator belong to the Doctrine Bridge? IMO no because when PSR-6 will be ready we will switch to this interface instead of Doctrine Cache but I'm open to suggestions. Same if you find a better name for the decorator. |
ping @symfony/deciders |
} | ||
|
||
/** | ||
* Retrieves the cached data if applicable or delegates to the decorated extractor.. |
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.
double dots
Looks like you need to rebase here (the namespace changes have been done in another PR). |
3ed99f3
to
436f650
Compare
Rebased and typo fixed. |
*/ | ||
private function extract($method, array $arguments) | ||
{ | ||
$key = $method.serialize($arguments); |
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.
just wondering: $arguments contains $context. But what does $context contain? Is it a big or small array of scalars? Something potentially non-serializable there?
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.
For now it is only used in Symfony by the serializer extractor (a small array of strings). But it's a good concern because the context can be used by any custom extractor and can contain anything.
Do you know a way to easily retrieve an unique identifier from an array or should we try something like recursively replacing instances of objects by the return of spl_object_hash()
?
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.
Maybe can we add a note in the doc of $context
in interfaces that it should only contain scalar and serializable objects or it will create unexpected side effects?
It will avoid to add a costly (in term of performance) custom serialization process here.
Committed a better way to handle context not serializable. /cc @nicolas-grekas |
use Doctrine\Common\Cache\Cache; | ||
|
||
/** | ||
* Adds a cache layer on top of an extractor. |
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 is not really meaningful.
Status: needs work Should be ported to PSR-6 |
bd1022c
to
335381b
Compare
335381b
to
9396a19
Compare
Status: Needs review Moved to PSR-6. |
@@ -34,6 +35,7 @@ | |||
"phpdocumentor/reflection": "<1.0.7" | |||
}, | |||
"suggest": { | |||
"symfony/cache": "To cache results", |
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.
"psr/cache-implementation": "For using the metadata cache.",?
@fabpot |
Thank you @dunglas. |
This PR was squashed before being merged into the 3.1-dev branch (closes #16917). Discussion ---------- [PropertyInfo] Cache support | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #16893 | License | MIT | Doc PR | todo Replace #16893 with several advantages: - Less complex patch - Work for all usages of PropertyInfo (even outside of the Serializer) - Avoid a circular reference between Serializer's CallMetadataFactory and PropertyInfo's SerializerExtractor - Allow @mihai-stancu's #16143 to work as-is Commits ------- 86c20df [PropertyInfo] Cache support
*/ | ||
class PropertyInfoCacheExtractorTest extends AbstractPropertyInfoExtractorTest | ||
{ | ||
public function setUp() |
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.
setUp is a protected method
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.
Quick search revealed there's few more occurrences. I'll send a PR to fix them.
Replace #16893 with several advantages: