The problem/use-case that the feature addresses
If I'm using a queue and I want to move more than 1 key list to another one, LMOVE command should be called the same quantity as values I want to move
Description of the feature
It could be useful to support an optional COUNT value, something like LMOVE <source> <destination> (LEFT|RIGHT) (LEFT|RIGHT) [count], similar functionality as LPOP https://redis.io/commands/lpop/. BLMOVE could be extended in the same way
Alternatives you've considered
Use LMOVE N times.
Comment From: hpatro
Thanks for filling the feature request. I see most of the other API has the count parameter, I don't see any issue adding this.
I see the response is currently a string for LMOVE (find the reply_schema below) and bringing in count parameter would require us to return back an array of elements. We could use the same strategy as LPOP i.e. it would be different response format based on the parameter in the request.
- LMOVE command
"reply_schema": {
"description": "The element being popped and pushed.",
"type": "string"
},
- LPOP command
"reply_schema": {
"oneOf": [
{
"description": "Key does not exist.",
"type": "null"
},
{
"description": "In case `count` argument was not given, the value of the first element.",
"type": "string"
},
{
"description": "In case `count` argument was given, a list of popped elements",
"type": "array",
"items": {
"type": "string"
}
}
]
},
Comment From: roggervalf
hi @hpatro, thank you for taking a look, I also created a pr for this new feature and follow the same pattern as in LPOP command, please when you get some free time to take a look
Comment From: hpatro
@roggervalf Let's get the core maintainers approval for this feature before jumping into the pull request review.
@madolson @oranagra What are you thoughts on this request ?
Comment From: madolson
I generally don't like variadic response schemas, since that means that clients have to understand the type of response based on the input arguments. It does seem like we have done it a number of times though (SPOP, LPOP).
I don't see any major caveats with the implementation. It should work pretty transparently with all of our blocking improvements. I guess the use case makes enough sense to me, I'd be fine moving forward with an implementation.
Comment From: niranjanhm-bh-git
Hi, I too was looking at such a need to move count elements from source to destination. Kindly take this feature on higher priority. Thanks for support.
Comment From: roggervalf
hi @niranjanhm-bh-git my pr was kind of outdated, but I fixed all merge conflicts in last version https://github.com/redis/redis/pull/12588 and tests passed. When you get some time @madolson @oranagra