Remove list when it's empty

[GoogleCodeExporter]

Ruby code:

  redis = Redis.new
  1_000_000.times do |i|
      redis.push_tail(i, i)
      redis.pop_head(i)
   end

Result:
   DB 0: 1000000 keys (0 volatile) in 1048576 slots HT.

All of them are empty lists. It would be nice if there would be a command like 
remove_if_empty 
or pop_tail/head_and_remove_if_empty. 

Original issue reported on code.google.com by libc.m...@gmail.com on 9 Nov 2009 at 3:18

[GoogleCodeExporter]

I would vote for a config variable 'remove empty lists/sets'.

Original comment by biruk...@gmail.com on 9 Nov 2009 at 11:09

[GoogleCodeExporter]

Yep, config variable is also ok for me.

Original comment by libc.m...@gmail.com on 9 Nov 2009 at 11:18

[GoogleCodeExporter]

It seems like a config variable to alter list key policy may cause apps to 
break when
used in different environments.

Why not just redefine list/set key existence as requiring at least one element 
and
always delete when empty?

Original comment by alexgrav...@gmail.com on 10 Nov 2009 at 8:05

[GoogleCodeExporter]

I think Alex's solution is sane *in theory*, but as usually the practice is 
another 
matter. Imagine a Set that is target of a lot of writes and that happens to end 
empty 
a lot of time. It can be for instance used for locking via SMOVE, or something 
like 
this.

If we remove empty objects what happens is that every time there is an insert 
operation Redis needs to rebuild the List or Set or ZSet object, and this is 
time 
consuming, so performances will suffer a lot under some kind of load, for 
instance 
when using a list as a queue that can be a common pattern.

So the problem is, are there a lot of real world scenarios were lists can get 
empty and 
are *not* likely to get new elements in the future? I never saw such a usage 
pattern, 
not that's impossible but my guess is that's unlikely to happen.

So currently I'm not sure about what's the best thing to do about this issue...

I'll take this issue open for now :)

Cheers,
Salvatore

Original comment by anti...@gmail.com on 10 Nov 2009 at 9:14

[GoogleCodeExporter]

This was fixed time ago and for all the available types.

Original comment by anti...@gmail.com on 23 Aug 2010 at 3:33

• Changed state: Verified