ISubsriber.WithPrefix and IConnectionMultiplexer.WithPrefix implementations #896
Conversation
|
For @NickCraver's benefit: this is related to an email discussion; I know this is something we've dismissed in the past, but I'm happy to look through the code and reconsider whether we should embrace it. |
|
I get the concept here (and agree with it), but seems like there has to be a much simpler implementation than constantly adding (or forgetting to add) to all wrappers. I'm curious on the scoping use cases - is this temporary, or for the life of the application? If the latter, it seems like a config option for suffice. Curious to hear more, only issue I'd have here is maintenance/testing...it'd add a bunch. |
|
Valid question. The scenario discussed on email was multi-tenancy, so very similar to our own usgae re keys. |
|
The main idea behind is having one connection multiplexer as a singleton in the application. We would like to add some profiling and monitoring on it. It is also quite convenient to have just one connection string to Redis (i.e. configuration) per application and changing it for each tenant. Current solution allows having multiple connection multiplexers with different channel prefixes (set in configuration), but you have to wrap the database object to use the same prefix. In other words, it is a little bit awkward to have a different approach for prefixing channels and keys. |
|
I've simplified this removing the ConnectionMultiplexer overhead, to where a user would cache a subscriber and a database if they wanted the pair, e.g. down to But the way it's prefixing is drastically different than |
|
When will this be completed? |
No description provided.