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

Make the default namepace name changable #2293

Open
1 of 2 tasks
PragmaTwice opened this issue May 5, 2024 · 8 comments
Open
1 of 2 tasks

Make the default namepace name changable #2293

PragmaTwice opened this issue May 5, 2024 · 8 comments
Labels
enhancement type enhancement good first issue Good for newcomers help wanted Good for newcomers

Comments

@PragmaTwice
Copy link
Member

Search before asking

  • I had searched in the issues and found no similar issues.

Motivation

It should be changable, as other namespaces.

Solution

No response

Are you willing to submit a PR?

  • I'm willing to submit a PR!
@PragmaTwice PragmaTwice added enhancement type enhancement help wanted Good for newcomers good first issue Good for newcomers labels May 5, 2024
@13015517713
Copy link
Contributor

I have learned kvrocks for some time. I have the will to implement that (or have a try).
There are two questions.

  1. Current namespace name is not modifiable, token can be modified by function(namespace set). Does changable 'name' refer to token?
  2. Default namespace is a literal value. How to make it modifiable, is it through config file ?

@PragmaTwice
Copy link
Member Author

Yeah, IIRC it's currently something like __namespace, but I think it's better to be changable.

I don't know which one is better: store in rocksdb or in the config file.

cc @mapleFU @git-hulk do you have any idea?

@PragmaTwice
Copy link
Member Author

Also another big issue is to be compatible to old version: users can use new version of kvrocks with their old data, and they want these old data can work well.

@git-hulk
Copy link
Member

git-hulk commented May 6, 2024

@PragmaTwice I'm not quite sure why we want to make it changeable. If for the space overhead consideration, it shouldn't take much more than the shorter one since the rocksdb has internal compression for the common prefix.

@PragmaTwice
Copy link
Member Author

Because I believe the default namespace should have the same status as other namespaces.
Currently, in kvrocks, the default namespace is a very special namespace, and admins cannot switch the default namespace to another one. This has some significant drawbacks, such as certain admin operations can only be performed in the default namespace.
I think this is a design flaw in kvrocks, and correcting it would require some cost at present.

@mapleFU
Copy link
Member

mapleFU commented May 6, 2024

Just curious why it should be changable? Is there any reason for that?

Because I believe the default namespace should have the same status as other namespaces.

It's a good reason but I think we have too many legacy user and perhaps this means maintaining two parts of code?

@PragmaTwice
Copy link
Member Author

If there is a good solution, we can avoid maintenance difficulties and correct this problem. (But TBH, design errors in the early stage will lead to unbearable costs, and everyone should understand this truth.)

Perhaps it's time for us to reconsider the authentication and permission management in kvrocks.

@git-hulk
Copy link
Member

git-hulk commented May 6, 2024

Currently, in kvrocks, the default namespace is a very special namespace, and admins cannot switch the default namespace to another one. This has some significant drawbacks, such as certain admin operations can only be performed in the default namespace.

We can achieve this by supporting the switch namespace API? The initial design didn't expect the admin to change data of other namespaces except to maintain the namespace/token pair itself. And I do agree the default namespace is very special, but it's to align with the Redis authentication way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement type enhancement good first issue Good for newcomers help wanted Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants