-
Notifications
You must be signed in to change notification settings - Fork 66
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
Switch what manager is the DefaultManager dynamically #73
Comments
To fix this "propertly" we need to add "setDefaultManager" to ManagerRegistry in doctrine commons: |
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 |
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. |
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 |
that sounds like a quite interesting idea! |
ping |
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 |
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 |
see #165 |
fixed in #165 |
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.
The text was updated successfully, but these errors were encountered: