Skip to content
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

Deprecate using doctrine/cache in favour of PSR-6 #144

Merged
merged 4 commits into from
Feb 13, 2021

Conversation

alcaeus
Copy link
Member

@alcaeus alcaeus commented Nov 27, 2020

This PR deprecates the getCacheDriver and setCacheDriver methods in the abstract metadata factory in favour of setCache and getCache which work with PSR-6 cache instances.

To make the transition easier, this PR provides a full backward and forward compatibility layer. When using setCache to use a PSR-6 cache, getCacheDriver will expose a doctrine/cache instance that wraps the PSR-6 cache. Similarly, when using setCacheDriver with a doctrine/cache instance, getCache will expose a PSR-6 cache that wraps the original cache.

The new protected getCacheKey method is used to avoid hardcoding cache keys in tests and can also be used by extending implementations to work with cache items directly (although they shouldn't).

Copy link
Member Author

@alcaeus alcaeus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left some feedback below.

@greg0ire what settings do I need to pass to update the lock file? Looks like psalm does not like something about this change, but I assume it's due to composer.lock changes, not the cache change itself.

"doctrine/event-manager": "^1.0"
"doctrine/event-manager": "^1.0",
"psr/cache": "^1.0",
"symfony/cache": "^4.4|^5.0"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used to provide the forward/compatibility layer. Once we drop that in 3.0, this becomes a dev dependency.

Copy link
Member

@greg0ire greg0ire Dec 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

symfony/cache has a dev-dependency on doctrine/cache, so this means a circular dependency (not for us, but for them when they are in dev mode). I think this might be OK though since it's not meant to last, and since symfony seems to be resorting to COMPOSER_ROOT_VERSION in its CI already: https://github.com/symfony/symfony/search?q=COMPOSER_ROOT_VERSION

Still, we might want to check if we don't break their pipeline after releasing this (or merging it? I think they have builds that use untagged versions).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is there a circular dependency? This is doctrine/persistence, not doctrine/cache.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is there a circular dependency?

symfony/symfony depends on doctrine/persistence and replaces symfony/cache. Anyway, we should be good here. 😃

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, nevermind my comment, not sure what I meant but I must have been confused.

@@ -400,6 +445,11 @@ public function getReflectionService()
return $this->reflectionService;
}

protected function getCacheKey(string $realClassName): string
{
return str_replace('\\', '__', $realClassName) . $this->cacheSalt;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This (along with the changed cache salt) will invalidate existing caches. We'll have to check if existing implementations manually mess with cache keys, in which case we'll have to come back and check the impact of this change.


$metadata = $this->createMock(ClassMetadata::class);
assert($metadata instanceof ClassMetadata);
public function testWillNotCacheFallbackMetadata(): void
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I duplicated that test, as I realised that using the onMetadataNotFound fallback does not cache that metadata. Since I assume this is intended, I haven't made changes and instead opted to codify that behaviour in tests.

@greg0ire
Copy link
Member

greg0ire commented Nov 27, 2020

I guess you will need to fix the conflicts for a new build to be triggered and the SA to be fixed (I merged up 2.1.x into 2.2.x, it contains a fix for your issue.)

@greg0ire
Copy link
Member

greg0ire commented Nov 28, 2020

My experience with doctrine/cache in paid projects is that it has bad framework integration, so I usually create a Symfony cache pool and wrap it in an adapter so that I can use it as a result cache for Doctrine and also see if the cache is used in the profiler. IMO this is the right move because it will mean we will not have to worry about things such as integrating doctrine/cache and a framework. Or maintaining that package. This is a great move IMO.

@alcaeus alcaeus requested a review from morozov November 29, 2020 10:28
@alcaeus alcaeus force-pushed the support-psr-6 branch 3 times, most recently from 4c21399 to 9b17158 Compare November 29, 2020 11:03
@alcaeus alcaeus requested a review from greg0ire November 29, 2020 11:03
@greg0ire
Copy link
Member

Not sure why there are this many PHPStan errors, but a lot of them look like they could be fixed by setting up phpstan/phpstan-phpunit.

@alcaeus
Copy link
Member Author

alcaeus commented Nov 29, 2020

Not sure why there are this many PHPStan errors, but a lot of them look like they could be fixed by setting up phpstan/phpstan-phpunit.

Not sure where those are coming from. The problem may be that I need to update the lock file due to dependency changes and it installs a newer version than it did before. We should probably document this in our contribution docs.

@alcaeus alcaeus force-pushed the support-psr-6 branch 2 times, most recently from ee2df30 to c2e4044 Compare December 12, 2020 12:06
@alcaeus alcaeus requested a review from greg0ire December 12, 2020 14:21
@alcaeus
Copy link
Member Author

alcaeus commented Feb 10, 2021

@greg0ire any idea why psalm suddenly complains about AbstractClassMetadataFactory::getMetadataFor? Nothing really changed in between, so I suspect that this is a psalm-related issue 🤔

@franmomu franmomu mentioned this pull request Feb 12, 2021
@greg0ire
Copy link
Member

Woops sorry I'm only noticing your ping now, and I think you are right, see #156

@greg0ire greg0ire closed this Feb 13, 2021
@greg0ire greg0ire reopened this Feb 13, 2021
@greg0ire
Copy link
Member

Ah I need to merge up

@greg0ire greg0ire merged commit cdfca25 into doctrine:2.2.x Feb 13, 2021
@greg0ire
Copy link
Member

Thanks @alcaeus !

@alcaeus alcaeus deleted the support-psr-6 branch February 15, 2021 15:13
public function setCache(CacheItemPoolInterface $cache): void
{
$this->cache = $cache;
$this->cacheDriver = new DoctrineProvider($cache);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should use the doctrine/cache PSR-6 provider instead, which is available in the latest version

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DoctrineAdapter could be replaced. I've created doctrine/cache#366 to also include this class in doctrine/cache so we no longer have external dependencies for the forward and backward compatibility layers. I'll follow up with a PR here once this is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants