Skip to content
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

Open
alrz opened this issue Mar 16, 2024 · 7 comments
Open

Accept key prefix in connection string #2676

alrz opened this issue Mar 16, 2024 · 7 comments

Comments

@alrz
Copy link

alrz commented Mar 16, 2024

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.

@NickCraver
Copy link
Collaborator

@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 prefix1 then the key is prefix1:key, but if .WithKeyPrefix() is called on the now-default IDatabase say with prefix2 would the result be:

  • prefix2:prefix1:key (what code would naively do)
  • prefix1:prefix2:key (actually a prefix-suffix)
  • prefix2:key (acting as an override)

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.

@alrz
Copy link
Author

alrz commented Mar 16, 2024

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)

@NickCraver
Copy link
Collaborator

@alrz Understood - I assumed the same, but all the questions remain :) What specific thing are you using that doesn't support this today?

@alrz
Copy link
Author

alrz commented Mar 16, 2024

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.

@mgravell
Copy link
Collaborator

If I may reframe/restate, is this correct?

  • ACLs in current Redis make key prefix more relevant
  • some client scenarios do not consider explicit key prefix APIs
  • therefore an implicit key prefix in the connection string would provide instant support to more scenarios

@alrz
Copy link
Author

alrz commented Mar 16, 2024

That's exactly correct, I believe.

@NickCraver
Copy link
Collaborator

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants