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

Command Migration: ('JSON.ARRAPPEND', 'JSON.ARRLEN', 'JSON.ARRPOP') #1026

Closed
4 tasks
AshwinKul28 opened this issue Oct 8, 2024 · 8 comments · Fixed by #1062
Closed
4 tasks

Command Migration: ('JSON.ARRAPPEND', 'JSON.ARRLEN', 'JSON.ARRPOP') #1026

AshwinKul28 opened this issue Oct 8, 2024 · 8 comments · Fixed by #1062
Assignees
Labels
migration -- command Migrates current eval to a refactored eval for all protocols functionality

Comments

@AshwinKul28
Copy link
Contributor

This issue tracks the migration of the mentioned commands - ('JSON.ARRAPPEND', 'JSON.ARRLEN', 'JSON.ARRPOP') to make them compatible across the three protocols supported by the Dice database: RESP, HTTP, and WebSocket.
DiceDB now supports more than one protocols (Resp/http/websocket). We don't want eval operation of each command to be strictly bound with any of the protocols. Currently eval function return statements of each command is bounded to the RESP protocol.

The migration is required because:

  • The current implementation is specific to the RESP protocol
  • Evaluation functions of each command must be refactored to ensure protocol-agnostic behavior.
  • Evaluation functions should return raw responses instead of protocol specific responses.

The goal is to make the command logic protocol-independent, allowing all three protocols to call the same core functionality seamlessly.

Requirements

  • Refactor the evaluation function of [Command Name] to be generic.
  • Ensure the evaluation function does not include protocol-specific logic.

Migration Steps

  1. Analyze Current Implementation

    • Review the current codebase to understand how the command logic is implemented.
  2. Refactor Return Logic

    • Create a new function with the function definition as evalXXX(args []string, store *dstore.Store) *EvalResponse under the file /internal/eval/store_eval.go
    • Analyse return statements of the eval and modify them to send raw types without encoding
    • Use errors in the return statements from /errors/migrated_errors.go file
    • Use perdefined responses from /internal/clientio/resp.go file as RespType variables
  3. Command/Worker specific Changes

    • Make IsMigrated flag to true in the commands information under /internal/eval/commands.go file.
    • Use the newly written eval function against the NewEval parameter in the same command structure.
    • Delete the old eval function from the /internal/eval/eval.go file.
    • Add the migrated command to the /internal/worker/CommandsMeta map and make it's type as SingleShard
  4. Update Unit Tests

    • Refactor existing unit tests to accommodate the new implementation.
    • Add new unit tests if necessary to cover all possible cases.
  5. Integration Tests

    • Run all integration tests to ensure successful migration.
    • Ensure that each protocol (RESP, HTTP, WebSocket) works correctly after migration.

Checklist

  • Migrated the evalXXX function with the latest definition
  • Update or add unit tests for the new implementation.
  • All unit tests pass successfully.
  • Ensure all integration tests pass successfully.

Additional Notes

  • Describe any edge cases that need to be handled in the generic function.
  • Mention any protocol-specific optimizations required in wrappers.

If there are any questions or concerns about this migration, please mention them here.

Related Issues/PRs

  • Sample implementation for the Get, Set, GetSet and SetEx can be found in this Pull Request.
@surya0180
Copy link
Contributor

@AshwinKul28, @lucifercr07 @JyotinderSingh I would love to work on this. Please assign this to me

@AshwinKul28
Copy link
Contributor Author

Hey @surya0180 assigned the other one to you. Thanks!

@psrvere
Copy link
Contributor

psrvere commented Oct 9, 2024

@AshwinKul28 - please assign this to me.

@lucifercr07
Copy link
Contributor

@psrvere I believe you have other issues assigned already, thanks for your interest. Let's give other folks chance to contribute.

@srivastava-yash
Copy link
Contributor

@lucifercr07 can i pick this?

@soumya-codes soumya-codes added new -- command migration -- command Migrates current eval to a refactored eval for all protocols functionality and removed new -- command labels Oct 17, 2024
@soumya-codes
Copy link
Contributor

soumya-codes commented Oct 17, 2024

@srivastava-yash I see you have made great progress in the other issue thats currently assigned to you. I am sure you will be able to raise a PR on this much faster. Please feel free to reach out to me or @AshwinKul28 if you have any questions or concerns.

@tarun-29
Copy link
Contributor

@lucifercr07 can i pick this?

@srivastava-yash are you still working on this issue?

@srivastava-yash
Copy link
Contributor

srivastava-yash commented Oct 22, 2024

@srivastava-yash are you still working on this issue?

@tarun-29 the PR for this is ready. The task took a little longer as there was an error in HTTP response writing. So once that PR got merged, I made changes here and its up for review currently.
Link -> #1062

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
migration -- command Migrates current eval to a refactored eval for all protocols functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants