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

Map deprecated Redis comments to its alternative if its already exist in Garnet #684

Open
17 of 21 tasks
Vijay-Nirmal opened this issue Sep 23, 2024 · 3 comments
Open
17 of 21 tasks

Comments

@Vijay-Nirmal
Copy link
Contributor

Vijay-Nirmal commented Sep 23, 2024

Feature request type

sample request

Is your feature request related to a problem? Please describe

Personally, I don't like to waste our time in implementing deprecated commands. But the issue is that these deprecated Redis comments will not be removed for years before they are removed completely. This means libraries and applications could still continue to use it even it's not recommented.

Describe the solution you'd like

I like to map deprecated comments to its alternative if it's already exist in Garnet

Describe alternatives you've considered

No response

Additional context

I can raise the PR for this if the garnet team is fine with this change.

List of all deprecated comments and their status on where are supported in Garnet

  • GEORADIUS_RO
  • GEORADIUSBYMEMBER_RO
  • SETEX
  • QUIT
  • SUBSTR
  • BRPOPLPUSH
  • GEORADIUSBYMEMBER
  • HMSET
  • PSETEX
  • ZREVRANGE
  • GEORADIUS
  • ZRANGEBYLEX
  • GETSET
  • RPOPLPUSH
  • ZREVRANGEBYLEX
  • ZREVRANGEBYSCORE
  • CLUSTER SLAVES
  • SLAVEOF
  • ZRANGEBYSCORE
  • CLUSTER SLOTS
  • SETNX
@yrajas
Copy link
Contributor

yrajas commented Sep 24, 2024

Good point. Thanks.
Please open a PR for this.

@Vijay-Nirmal
Copy link
Contributor Author

@yrajas Should the deprecated command need to be added as part of IGarnetApi or can it be mapped to the alternative in the network layer (RespServerSession) itself?

@yrajas
Copy link
Contributor

yrajas commented Sep 30, 2024

The main advantage of adding support for these older commands is primarily to expand compatibility with existing clients. So, as long as the parsing is supported and mapped to an existing command, we should be good.

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

2 participants