Thanks to visit codestin.com
Credit goes to github.com

Skip to content

RedisStore does not follow the StoreInterface for waitAndSave #28694

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

Closed
nesl247 opened this issue Oct 2, 2018 · 4 comments
Closed

RedisStore does not follow the StoreInterface for waitAndSave #28694

nesl247 opened this issue Oct 2, 2018 · 4 comments

Comments

@nesl247
Copy link

nesl247 commented Oct 2, 2018

Symfony version(s) affected: 4.1.*

Description
RedisStore does not properly follow StoreInterface's docblock.

Possible Solution
Instead of throwing InvalidArgumentException it should throw `NotSupportedException

Additional context
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Lock/StoreInterface.php#L37
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Lock/Store/RedisStore.php#L77

@chalasr
Copy link
Member

chalasr commented Oct 2, 2018

Same for all other methods actually, they all rely on RedisStore::evaluate() without catching the exceptions it might throw. \cc @jderusse

@jderusse
Copy link
Member

jderusse commented Oct 3, 2018

@nesl247 good catch, it's a mistake. Would you mind to open a PullRequest?

@chalasr should we wrap every external call in a try/catch in order to return an expection Symfony\Component\Lock\Exception\ExceptionInterface instead of the raw original exception? (same goes for evey stores (DBAL, Memcahced, ...)

@nesl247
Copy link
Author

nesl247 commented Oct 3, 2018

I'd be happy to open a PR for it. I'll add it to my todo.

fabpot added a commit that referenced this issue Jul 8, 2019
… with less responsability (Simperfit)

This PR was squashed before being merged into the 4.4 branch (closes #32198).

Discussion
----------

[Lock] Split "StoreInterface" into multiple interfaces with less responsability

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | no
| New feature?  | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | Contribute to #28694 <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | TODO <!-- required for new features -->

<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/roadmap):
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too).
 - Features and deprecations must be submitted against branch 4.4.
 - Legacy code removals go to the master branch.
-->

We are removing the StoreInterface in order to split into multiple interface, it will help reduce de responsability of the StoreInterface.

Firstly, since not all stores needs to have all the methods of the StoreInterface, we can split this like this in order to limit the methods that are needed for each store.

Secondly, we add supportsX methods in order to avoid throwing exception when a store does not supports a feature it's easier an instance of the special interface or not, and it can return true/false on the support method.

**Really big thanks to** @jderusse for working with me on this, 1-2 hours of talking together, and another 1-2 hours of pre-review :). now giving it to the whole community !

*some time has been sponsored by* @izisolutions

Commits
-------

91fcbea [Lock] Split \"StoreInterface\" into multiple interfaces with less responsability
@Simperfit
Copy link
Contributor

@fabpot this can be closed

@fabpot fabpot closed this as completed Jul 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants