Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Allow optional wrapping of stores and strategies
See original GitHub issueWhat is the problem?
I’m currently facing the following issue: until recently (I think 3.1.0) store implementations didn’t use to get wrapped. This allowed me to do some “rather unclean” things like implementing the store interface, requiring the store interface via DI and then pattern match on my custom implementation to get more functionality (like a GetAllTenants method). Using the included extension methods I can’t register unwrapped types anymore which currently breaks me in runtime.
Why do I do those hacky things?
I have two cases in which this hacky way of working with DI is quite useful for me.
- In development when starting up the application and applying automatic migrations on all known dev tenants
- In integration tests when dynamically doing the same for in-memory databases
What workarounds do I currently have?
I can write my own extension methods to add strategies. I suppose that’s the cleanest way of doing it right now. I can also revert to 3.0.1 where the wrapping doesn’t happen yet.
Possible solutions?
- Make wrapping optional (would be nice anyway as I might to do all my logging on my own)
- Expose the wrapped Type via an accessor in the wrapper (not really beautiful though)
What do you think about it? I personally would go with option one but maybe I don’t have the full picture. If you think that this would be a sensible approach I could prepare a PR.
Kind regards Gregor
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@WalternativE Hi thanks for this feedback and your other comment.
In taking a quick look at the code I think I want to have it so the instance stored in the MultiTenantContext is the “inner” one – I already adjusted the code to show the Type of the inner one so it would make sense that the inner one does too. I’ll probably add a property to the wrapper class to access the inner instance for this purpose.
Thanks!
@achandlerwhite
I took a look at the PR and it looks like exactly the thing I need for my use case 😃 Thank you very much!