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
Accept key prefix in connection string #2676
Comments
@mgravell I remember there was a reason we never implemented this, including when Stack used it and channelPrefix was added...but I can't recall why now, any chance you remember? I'm admittedly not sure how the behavior would with the existing methods kick in, e.g. would they concat an additional prefix? That's likely counter to what's wanted because "starts with" it usually the intuitive behavior. For example if the base was
Things like this come into play if there's some global default. Each of the above options is arguable, but not intuitive, and the last could allow an "escape" is the intent is to encapsulate keys inside an external prefix. It may be just because of the above questions that we leave it to downstream libraries, because there are behavioral decisions in supporting it. |
Note that the reason for this is that clients may only access to a specific key prefix so I think the one specified in connection string should be considered the global default (not overridable) |
@alrz Understood - I assumed the same, but all the questions remain :) What specific thing are you using that doesn't support this today? |
I've filed this for Orleans as well. This was kind of blocking due to the keyspace perm but didn't find it in either side. |
If I may reframe/restate, is this correct?
|
That's exactly correct, I believe. |
If the intent is ACLs, then it seems like the intended behavior wouldn't be something like "globalKeyPrefix", which always comes first for all commands (would it apply to channels? Or no because there exists an option for that which could be set too?) |
using WithKeyPrefix must be supported in each library that depends on SE.R. It would really help if we could pass the prefix in the connection string just like defaultDatabase.
The text was updated successfully, but these errors were encountered: