You can clone with
HTTPS or Subversion.
We need to be able to change the default manager name on the ManagerRegistry to enable, for example, changing from Preview ro Staging workspaces depending on the domain.
We can currently do this by hacking the PHPCR-ODM ManagerRegistry and returning and modifying our own defaultManagerName.
To fix this "propertly" we need to add "setDefaultManager" to ManagerRegistry in doctrine commons:
/cc @fazy, @lsmith77
that is going to take time until it will be possible, even if the doctrine crowd agrees.
so for now we need to keep track of who is using the manager and update them all? alternatively we could extend the ManagerRegistry and try to hide the private defaultManagerName with our own field that has a setDefaultManager method. could be a bit hackish but should not be too bad i think.
we discussed this and felt it was a relevant enough use case to support it. going through and updating the document manager everywhere seems like a lot of overhead .. especially since many of these services will in the end not get called again to actually do something with the new document manager. furthermore its hard to know which service has actually decided on its own to use a different document manager for some reason.
as such we decided that it would be best to completely override the "default" connection and manager in the ManagerRegistry (as it is private) atm. it will mean some additional code in our ManagerRegistry implementation but not a lot of logic. we will then also submit a PR for Symfony 2.4 to make this a core feature.
/cc @stof @beberlei
This is a problem the DIC has to solve, not the registry
Not sure how the DIC can help here. In a sense we are using the ManagerRegistry as a more limited DIC (or rather service locator). We need to be able to change the document manager multiple times if needed within the same request.
Ah ok i get the requirement now. Not sure if hacking the "default" feature here is a good way, as this is a different concept than having a "staging" and "live" database, which are valid domain concepts in the CMS world.
Could the developer simply supply a different implementation of the PHPCR manager registry that could infer the workspace from something (i.e. the request or a custom class) ? /cc @fazy
ping again. as we are nearing the 1.1 release, this would be a moment to introduce this.
i think the way to go is simply to extend Doctrine\Bundle\PHPCRBundle\ManagerRegistry and then configure doctrine_phpcr.class so nothing needs to be done in the bundle. does that make sense?
but we currently do not make this class configurable from what I can tell .. so that should be done.
its a parameter in the DI https://github.com/doctrine/DoctrinePHPCRBundle/blob/master/Resources/config/phpcr.xml#L10 (though one with a funny name)
yes .. but it is not configurable via the Bundle config .. overwriting DI parameters of Bundles is not a good idea
fixed in #165