-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console][Lock] Allow LockableTrait to use custom stores #31914
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
Conversation
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.
Some comments. Thank you for the PR.
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/Tests/DependencyInjection/AddConsoleCommandPassTest.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/DependencyInjection/AddConsoleCommandPass.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/DependencyInjection/AddConsoleCommandPass.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/DependencyInjection/AddConsoleCommandPass.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/Tests/DependencyInjection/AddConsoleCommandPassTest.php
Outdated
Show resolved
Hide resolved
|
||
$storeDefinition = 'lock.default.store'; | ||
if ($container->hasDefinition($storeDefinition)) { | ||
if (\method_exists($definition->getClass(), 'setStore')) { |
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'm a bit unsure about injecting the store based on method existence.
This is about autoconfiguration which usually works on types, and traits are not types. Should we add a marker LockableInterface
and use it as a type for ContainerBuilder::registerForAutoconfiguration()
?
* | ||
* @param StoreInterface $store | ||
*/ | ||
public function setStore(StoreInterface $store) |
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.
what about passing a non-default store as optional 3rd arg in lock()
? and avoid this state issue.
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.
meaning the user injects his own store if needed
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.
If that's the case then this change wouldn't be needed because you can implement the Symfony\Component\Lock\Factory
service in a command by dependency injection to create locks.
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.
Right ... the user can also set private $store;
already.Then, im not sure what we're solving here 🤔
We should favor pure DI / service usage IMHO.
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'm trying to solve a configurable store that can be used in commands, this can either be done by:
- The current solution (setStore in
LockableTrait
); - Implementing a default store in
Symfony\Component\Console\Command\Command
; - Writing a
LockableCommand
class which basically does what LockableTrait does now, so this could mean bye bye for LockableTrait - would also mean more abstraction;
Why?
Because currently LockableTrait
is limited to SemaphoreStore
and FlockStore
. Also you can use dependency injection but that would mean that you have to overwrite the constructor. Last, it's not configurable as in available in a command by default.
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.
you can use dependency injection but that would mean that you have to overwrite the constructor.
Is that a real problem? IMHO it's the explicit way.. compared to calling an arbitrary setStore
method. At least i agree with https://github.com/symfony/symfony/pull/31914/files#r294103123; if we do this we should add a marker interface for it.
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 agree that we should be using a marker interface. I've updated the PR.
e4d791f
to
c05870e
Compare
… the AddConsoleCommandPass
…ConsoleCommandPass" This reverts commit bd46276
…ForAutoConfiguration Added LockableInterface as marker
… the AddConsoleCommandPass
…ConsoleCommandPass" This reverts commit bd46276
…ForAutoConfiguration Added LockableInterface as marker
045a7ac
to
bbfb8aa
Compare
Bump, requesting new review after proposed changes. |
@jderusse Can you have a look at this PR? |
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.
Wonder if the marker couldn't be replaced by a autowired setter?
trait LockableTrait
{
/**
* @required
*/
public function setStore(StoreInterface $store)
{
$this->store = $store;
}
}
class OverrideStoreCommand
{
use LockableTrait;
/**
* @required
*/
public function setStore(StoreInterface $notdefaultLockStore)
{
$this->store = $store;
}
}
use Symfony\Component\Lock\Store\FlockStore; | ||
use Symfony\Component\Lock\Store\SemaphoreStore; | ||
use Symfony\Component\Lock\StoreInterface; |
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.
beware, the interface has been renamed in #32198
No need to add a setter, named autowiring aliases can be used instead. |
This PR adds the possibility to inject a custom store which implements the StoreInterface in a command by doing the following:
LockableInterface
to the command;Symfony configuration:
If those two conditions are met in the AddConsoleCommandPass, the setStore method will be called and the store of choice will be set.I had difficulty choosing the best solution while keeping simplicity in tact. A different solution would be to add this functionality to the base command (Symfony\Component\Console\Command\Command) and make it configurable.
If no store is configured the LockableTrait will work as it was, by either giving the SemaphoreStore or the FlockStore.