-
Notifications
You must be signed in to change notification settings - Fork 180
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
Injecting custom instance of IConnectionMultiplexer
#106
base: main
Are you sure you want to change the base?
Conversation
…or handling custom lifecycle of StackEchange.IConnectionMultiplexer.
IConnectionMultiplexer
@footcha I haven't got time to look into this yet. Once I am done with my current task, I will verify this and update this thread. Sorry for the delay |
@SiddharthChatrolaMs Is there any progress in a code review? Any estimate when you will be able to provide a feedback? |
Our team is pretty slammed right now and we probably wont get to this right away. One thing that jumps out at me is some concern over the fact that you are using an interface for the factory, which makes future changes/behaviors around controlling the multiplexer challenging. At the very least, I would think we should consider an abstract class instead of the interface, which would allow us to add new, virtual methods if the need arises. However, if you have other suggestions, those would be great to hear. |
@JonCole Thank you for a response. I understand your suggestion to replace an interface-based factory with an abstract class. I will do that. |
@footcha - one of the other things that I am concerned about with this PR is the fact that this effectively exposes some internal abstractions that aren't necessarily designed sufficiently to be ready for public consumption. For instance, before accepting this PR, I would want to think about how far we think we want to take the abstraction around the connection. Do we want to allow app developers to control the calls to the multiplexer? Do we want to let developers replace StackExchange.Redis entirely with some other client library? I think we need to answer some of these longer term plans around extensibility before we can decide if your PR has the right long-term design. Unfortunately, our team doesn't currently have the cycles to spend time digging into the longer term extensibility plans, thus the desire on my end to wait a bit longer before acting on this PR. Happy to hear thoughts/feedback from you and others as well on this topic... |
Hello, has someone already time to finish review/merge? @JonCole ? @SiddharthChatrolaMs |
Hey sorry about the delay but our team has been pretty busy. |
This PR contains initial implementation of #105.
Your feedback is welcome.
Thank you for your work!
BR
Petr