-
Notifications
You must be signed in to change notification settings - Fork 47
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
Don't cache entities #46
Comments
I'd agree with your suggestion 👍🏽 |
hey @vienthuong thanks for your feedback. just pushed the changelog 👍 |
Hi @ckilb |
Hey @vienthuong |
@ckilb Sorry for the late response, |
Right now hydrated entities are cached in
\Vin\ShopwareSdk\Repository\Traits\EntityHydrator::hydrateEntity
$cacheKey = $entityRaw['type'] . '-' . $entityRaw['id'];
if (array_key_exists($cacheKey, $this->cache)) {
return $this->cache[$cacheKey];
}
This should imo get removed without replacement.
I'd not expect the SDK to do caching for me. In case I want caching I could easily implement it on my own.
There are some downsides of caching:
If you search for an entity without associations and later on search for the same entity with association, the "new" hydrated entity is actually the old one without the associations added -> this is what took me quite some time to figure out.
If you use some web server that doesn't end the PHP progress after the request has been finished this value will be cached forever. Even if the next request comes in after minutes/days/weeks the old value of that entity is still cached. I know common webservers like Apache or Nginx with PHP-FPM start a new process with each request - but new approaches are coming and get more and more popular (Swoole, Roadrunner).
Like I said I don't think caching is necessary (the request to actually get the entity data from Shopware is probably much slower than hydrating the entity) so I'd remove it. In case you think caching should still be present it would be nice to be able to enable/disable it (via Context flag?) or at least to clear it (via method call).
===
Another proposal related:
For now I'd like to replace the method hydrateEntity with my own. If hydrateEntity would be public, EntityHydrator would be a class that get's initialized by some factory and injected to the EntityRepository this would be quite easy.
But as hydrateEntity is a private trait method inside a Trait which is hardly coupled to EntityRepository this is a bit tricky to do.
In general I'd suggest - at least for a library - to avoid Traits and rely on DI instead.
===
PR: #47
The text was updated successfully, but these errors were encountered: