Bundles already handle this by defining a set of backend specific services as private, and setting an alias for the appropriate one to a primary service id based on configuration. Private services not referenced get removed by a cleanup compiler pass.

https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/config/orm.xml#L8 defines a default service, and the extension class then sets an alias based on its configuration: https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/DependencyInjection/FOSUserExtension.php#L48

This lets the developer define their own service and tell the extension about it and that it should become the manager.

What the code of drupal allows is something like the following:

lock:
class: Drupal\Core\Lock\Lock...
myqsl.lock:
class: Drupal\Core\Lock\Lock...
sqlite.lock:
class: Drupal\Core\Lock\Lock...

As a site adminstrator you just need to set 'default_backend' and mysql.lock will be automatically aliased to lock

The code I linked achieves the same thing.

I don't see how this is done in a generic way for all possible storages.
Can you enlighten me?

On Thu, Jul 24, 2014 at 11:40 AM, Tim Nagel notifications@github.com
wrote:

The code I linked achieves the same thing.

—
Reply to this email directly or view it on GitHub
#11460 (comment).

@dawehner You define every possible storage as private service and you use a (non-yet used) service-id as dependency for every occurence, where one of this storages is required. In your Extension-class you read the configuration and set this not yet known service-ID as an alias onto one of the existing (private) services depending on the configuration.

$storageName = $config['storage']; // For example "redis"
$container->setAlias('foo_bar.storage', "foo_bar.storage.$storageName");

or if you want it super-generic use the full qualified service id in the configuration instead (that's what you can see in the links given by @merk )

So it is not automatic as proposed in the issue ... This is not a support
question
On Jul 24, 2014 11:47 AM, "Sebastian Krebs" notifications@github.com
wrote:

@dawehner https://github.com/dawehner You define every possible storage
as private server and you use a (non-yet used) service-id for every
occurence, where one of this storage should appear. In your Extension-class
you read the configuration and set this not yet known service-ID as an
alias onto one of the existing (private) services depending on the
configuration.

$storageName = $config['storage']; // For example "redis"$container->setAlias('foo_bar.storage', "foo_bar.storage.$storageName");

—
Reply to this email directly or view it on GitHub
#11460 (comment).

It can be handled by a simple compiler pass that looks for a parameter and handles this without tags. I'm not talking about support - I'm mentioning that this is already possible with very little additional effort on top of a container.

I totally don't argue against that, I think we have kind of a communication problem.

I just wanted to ask whether symfony would like to have such an automatic backend switching system included, maybe in FrameworkBundle.

I don't think it can be in FrameworkBundle. You can have different bundles supporting to choose their backend while the choice in one is totally independant from the choice in others (potentially with different values for the choice items btw). Making something generic in FrameworkBundle would probably end up being more complex than having the bundle handling the config it needs.

Just talked with @Crell about this one.

So, basically, that's interesting but if it should be more generic than the Drupal use case.

The problem Drupal is trying to solve is to automatically create aliases based on some parameter value. We could imagine a tag that makes this easier to achieve, based on some conventions/options:

lock:
    class: Whatever
    tags:
        - { name: auto_alias, { parameter_name: default_backend, format: "%s.lock" }  }

parameters:
    default_backend: mysql

And the compiler would make lock an alias for mysql.lock.

I like the more generic format @fabpot suggests. It's a little bit more wordy for the person setting up the service but gives more flexibility. (One could have multiple "classes" of swappable services this way, which is nice.) I don't know if we could switch Drupal's syntax to that now that we're in beta but I would not object to doing so.

It seems that we all agree on the last @fabpot proposal. So the question is, who's gonna prepare the PR for this change? @Crell do you prefer if some Drupal developers take this responsibility? @fabpot do you prefer to do this PR yourself?

@javiereguiluz I don't have any special recommendations here, except that it's going to be in 2.7.

Which hopefully will be the version in which d8 ships

I'm OK with an API change in Drupal to use the Symfony format if that's added since the one we added isn't used much yet. However the change would need to be made before we start supporting an upgrade path between betas (which doesn't have an explicit timeframe - it's tied to issues fixed).