Command Migration: ('PFADD', 'PFCOUNT', 'PFMERGE')
This issue tracks the migration of the mentioned commands - ('PFADD', 'PFCOUNT', 'PFMERGE') 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
-
Analyze Current Implementation
- Review the current codebase to understand how the command logic is implemented.
-
Refactor Return Logic
- Create a new function with the function definition as
evalXXX(args []string, store *dstore.Store) *EvalResponseunder 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.gofile - Use perdefined responses from
/internal/clientio/resp.gofile as RespType variables
- Create a new function with the function definition as
-
Command/Worker specific Changes
- Make
IsMigratedflag to true in the commands information under/internal/eval/commands.gofile. - Use the newly written eval function against the
NewEvalparameter in the same command structure. - Delete the old eval function from the
/internal/eval/eval.gofile. - Add the migrated command to the
/internal/worker/CommandsMetamap and make it's type asSingleShard
- Make
-
Update Unit Tests
- Refactor existing unit tests to accommodate the new implementation.
- Add new unit tests if necessary to cover all possible cases.
-
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.
@AshwinKul28, @lucifercr07 @JyotinderSingh I would love to work on this. Please assign this to me
Thanks @surya0180 go for it 🚀
HI @surya0180 , I hope you are doing well. Do you happen to have any updates on this? If you've any doubts please let us know on the discord.
Hi @AshwinKul28. I am still exploring the codebase to better understand how things get triggered through different protocols. Working on Go language after a long time, its taking sometime for me to understand few things, but its actually done now. I am going to send a PR by EOD or at max by tomorrow morning!.
Thanks!
@AshwinKul28, There is a method in eval_test called runEvalTests, which runs the tests for the given eval function. Initially, this function was written for RESP only. However, since we are now supporting multiple protocols, we need to add a new function that does the same but accepts an eval function with a return type of EvalResponse. Based on what you shared in this issue, you referenced a PR that includes the migration of GET, SET, GETSET, etc., but I am unable to find the new method required to execute these new eval functions.
Could you please advise if we need to write the logic for this function inside our eval functions, or is there a reusable function we can use?
Hi @surya0180 thanks for the update.
Based on the sample PR, you need to migrate the current Eval function to the new one by moving it to the store_eval.go file and making required changes which returns *EvalResponse in return. You may need to make changes in the respective unit test functions.