In currently, LPOP and RPOP can only pop 1 element from the list. which is not effective. Suggest to allow pop more elements, like LRANGE, to accept a range between start and end index.
Comment From: kripod
Bump, this is a great idea! :+1:
I propose an optional count argument for both LPOP and RPOP methods to be added.
Example:
- RPOP mylist 3, where 3 is the amount of items to remove from the list.
- If mylist has less than 3 elements, then return every element as a result.
Comment From: antirez
Looks interesting and makes sense to me. This is also backward compatible, since, if no count is provided, an element is returned as usually, otherwise the command switches to return an array of items.
Comment From: oranagra
@felipou seems in the area of your recent work, maybe you'll want to pick this up.
Comment From: felipou
Ok, I'll take a look!
Comment From: felipou
I liked @kripod 's idea, and it also simplifies the blocking version. The count becomes actually a "maximum" number of elements. - "RPOP list 3" would pop a maximum of 3 elements. - "BRPOP list 3" would block if list is empty, but unblock as soon as there is at least one element pushed, when it would pop a maximum of 3 elements as RPOP.
I'll try to implement it like this.
Comment From: felipou
Ok, I just started drafting an implementation, got it working for RPOP/LPOP, but when I looked into the blocking variant, I remembered the "timeout" argument and the fact that you can pass multiple keys as argument to BRPOP/BLPOP. So basically, we can't have an optional "count" argument there. Now I understand why ZINTER and ZUNION have the numkeys argument :sweat_smile:
Right now I can't think of a way to add a "count" or "COUNT count" argument to BRPOP/BLPOP without breaking compatibility. Any ideas? Should I just ignore the blocking variants for now?
Comment From: felipou
My implementation so far: https://github.com/felipou/redis/commit/a8b156918b27def14d5bb623cfd9727839d5eb37
Comment From: oranagra
i suppose the only way out of this is to create a new command and deprecate the old one. we can add a BLOCK argument to LPOP (like we have for XREAD) or we can create a new BPOP command that will take LEFT|RIGHT
@redis/redis-contributors any other suggestions or feedback? (context, can't add COUNT argument to BLPOP due to it's syntax).
I suppose we don't have any problem with a command that has an argument that turns it into a blocking command (like XREAD does). in any case, a blocking command like BLPOP may many times return without blocking. If we see any reason for someone (ACL or others) to treat BLPOP differently than LPOP, we have an issue with XREAD anyway.
the only complication i remember is that XREAD has a special if to ignore / reject the BLOCK argument when it runs inside a LUA / MULTI.
Comment From: itamarhaber
@felipou are you pushing this or shall I take over?
I think we're aligned with adding the optional [COUNT count] to (L|R)POP, and introducing more-suitably-APIed B(L|R)POPEX variants? We'd like to have it ready in a week's time so it can be considered for 6.2-RC1.
Comment From: oranagra
@itamarhaber i think adding a BLOCK <timeout> argument to LPOP is the right move (and deprecated BLPOP).
would make it similar to XREAD in that sense.
do you see any reason to avoid such a thing? is there someone to consult with? (client library authors?), did you ever see any feedback about a problem with XREAD not having a specific command variant that can never block?
Comment From: itamarhaber
(L|R)POP are single-key, whereas the blocking variants are multi - I'm not sure about is there's a justification for making the former variadic.
Comment From: oranagra
i can imagine someone can find that useful. similar to other APIs in "nature", like select on multiple sockets, sometimes you want to block until timeout, sometimes the timeout is infinite, and sometimes you just want an instant peek.
it does mean though that as soon as you add multiple keys, the response needs to carry the keyname from which you ended up popping (which is ok, since the arguments dictate the response type).
but maybe indeed that justifies for a new command. how about:
LMPOP numkeys key key2 LEFT|RIGHT [COUNT max] [BLOCK timeout]
Comment From: felipou
@felipou are you pushing this or shall I take over?
@itamarhaber Please do take over if you can, I probably won't be able to properly work on this to finish it in a week.
Comment From: oranagra
this task became a bit more complicated and might not be realistic for 6.2 RC1, but maybe we can still make it fit RC2 (if someone is able to carry it through).
Comment From: madolson
Looks done to me.
Comment From: oranagra
@madolson we only added COUNT argument to the non blocking variants. Adding it to the blocking variants meant creating a new command since the existing one can't be extended. I think we want to reopen (and maybe rename) this one. Right?
Comment From: madolson
Oh, I have a note that we decided it was not worth pursuing from our monthly sync notes. We spent a bunch of time mulling over the different options, and just decided to go with extending the count and not implementing the blocking variant. However, I don't see a reason we can't keep this open in case we pursue the blocking variant later, I'll update the title for those that come along.
Comment From: madolson
I'll add the other context from our sync, which was that we preferred new blocking commands over extending existing commands with a blocking argument.