Skip to content

[Bridge/Doctrine] Use cache.prefix.seed parameter for generating cache namespace #20616

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

Merged
merged 1 commit into from
Nov 25, 2016

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Nov 24, 2016

Q A
Branch? 3.2
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

Exactly the same issue as in #20610, but for Doctrine ORM's cache:

That's a design issue: using root_dir as discriminant doesn't work with blue/green deployment strategies, and doesn't prevent collision when different apps are deployed in the same path while sharing the same cache backend.

@nicolas-grekas nicolas-grekas added this to the 3.2 milestone Nov 24, 2016
@nicolas-grekas nicolas-grekas force-pushed the cache-seed-doctrine branch 7 times, most recently from a5609c7 to 5b47181 Compare November 24, 2016 13:51
if ($container->hasParameter('cache.prefix.seed')) {
$seed = '.'.$container->getParameterBag()->resolveValue($container->getParameter('cache.prefix.seed'));
} elseif ($container->getParameter('kernel.debug')) {
$seed = '_'.$container->getParameter('kernel.root_dir');
Copy link
Member Author

@nicolas-grekas nicolas-grekas Nov 24, 2016

Choose a reason for hiding this comment

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

What do you think about reintroducing kernel.root_dir but only when kernel.debug is true, so that locally running apps have separate cache namespaces by default?

Copy link
Member

Choose a reason for hiding this comment

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

I am not convinced that this is a good idea as it will force developers you deploy more than one application to the same server that share the same cache backend to always configure the cache.prefix.seed option.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed. I updated the code to use cache.prefix.seed when available, or kernel.root_dir as fallback. Looks better to me also.

@nicolas-grekas
Copy link
Member Author

Ping @symfony/deciders , we need to make a decision on this one before the end of the week for 3.2 to be ready (2/3).

@lyrixx
Copy link
Member

lyrixx commented Nov 24, 2016

👍

@nicolas-grekas nicolas-grekas force-pushed the cache-seed-doctrine branch 2 times, most recently from 2575d74 to 3f3733b Compare November 24, 2016 20:34
@xabbuh
Copy link
Member

xabbuh commented Nov 25, 2016

👍

Status: Reviewed

@nicolas-grekas nicolas-grekas merged commit 5e3cbec into symfony:3.2 Nov 25, 2016
nicolas-grekas added a commit that referenced this pull request Nov 25, 2016
…rating cache namespace (nicolas-grekas)

This PR was merged into the 3.2 branch.

Discussion
----------

[Bridge/Doctrine] Use cache.prefix.seed parameter for generating cache namespace

| Q             | A
| ------------- | ---
| Branch?       | 3.2
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Exactly the same issue as in #20610, but for Doctrine ORM's cache:
> That's a design issue: using root_dir as discriminant doesn't work with blue/green deployment strategies, and doesn't prevent collision when different apps are deployed in the same path while sharing the same cache backend.

Commits
-------

5e3cbec [Bridge/Doctrine] Use cache.prefix.seed parameter for generating cache namespace
@nicolas-grekas nicolas-grekas deleted the cache-seed-doctrine branch November 25, 2016 09:51
@fabpot fabpot mentioned this pull request Nov 27, 2016
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.

4 participants