Stream feature polish

[byroot]

While playing with #799 locally, I realized it uses some modern Ruby feature like Array#concat varargs signature.

This PR updates the builds matrix so that it spots more of this kind of issues.

I'll wait for the results and fix what comes up.

[byroot]

cc @supercaracal just so you know.

[byroot]

I updated the rubies to recent point releases, and dropped 2.2.x since it's now EOL. The matrix is already huge so we can't realistically test EOL versions.

[supercaracal]

Are we able to update required_ruby_version?

[byroot]

The idea here is to test all the versions of the server with the ruby driver, but only the most recent one with the alternative drivers. I believe it's a good compromise between coverage and matrix size.

[supercaracal]

Perhaps, do we need JRuby x Redis 5.0 pattern?

[byroot]

That's the only one we should test actually IMO.

[byroot]

0a0cb11

[byroot]

@supercaracal another thing I spotted and I'd like your opinion on. XREAD returns a hash of a hash:

>> pp r.xread('mystream', '0-0', block: 50_000)
{"mystream"=>
  {"1544447512733-0"=>{"f1"=>"v1", "f2"=>"v2"},
   "1544447564923-0"=>{"f1"=>"v2", "f2"=>"v5"}}}

I wonder if it actually make sense, and if arrays wouldn't be more appropriate:

{"mystream"=> [
  ["1544447512733-0", {"f1"=>"v1", "f2"=>"v2"}],
  ["1544447564923-0",{"f1"=>"v2", "f2"=>"v5"}]
]}

Granted, hashes are ordered in Ruby, but I'm not sure addressing the result by id actually make sense. What do you think?

[supercaracal]

@byroot I think so too. I'm sorry. Hash is excessive abstraction. Array is more intuitive than Hash.

[byroot]

No need to be sorry !

[byroot]

@supercaracal I pushed a change so that we use start and end as params to be consistent with the server docs. Mind taking a look when you have time?

[supercaracal]

@byroot 👍 I agree it. It is match Redis' API one-to-one. There is no learning cost for user.

[byroot]

Actually I'm now wondering if we should use named arguments at all for start and end.

def xrange(key, start='-', _end='+', count: nil)
def xrevrange(key, _end='+', start='-', count: nil)

That's probably as easy to use if not more ^

[supercaracal]

👍 It is more consistent than keyword arguments.

e.g.

• #getrange
• #lrange
• #zrange
• #zrevrange
• #zremrangebyrank
• #zrangebylex
• #zrevrangebylex
• #zrangebyscore
• #zrevrangebyscore
• #zremrangebyscore

[supercaracal]

Perhaps, we should use named optional arguments for the count option too. e.g. #spop #srandmember

[byroot]

I think named arg for count make sense.

I feel like a common use for xrange is "give me the last X events", so xrange(key, count: X)

Another likely common use case is "give me events since X, but no more than 50", so xrange(key, last_id, count: 50).

[supercaracal]

Certainly. I understand.

[supercaracal]

I'd say that the use cases of specifying XRANGE's end or XREVRANGE's start are rare.

I think that the following argument pattern is easy-to-use and consistent.

• start or end options are named optional arguments
• count option is keyword argument

[byroot]

I'm not sure I understand the distinction you make between keyword and named arguments. Care to explain ?

[supercaracal]

I'm sorry. I made a mistake. I chose wrong English word. s/named/optional/

[supercaracal]

I apologize for the above my confused comments. I mixed up the named arguments and the optional arguments. The named arguments are same as the keyword arguments. I'm sorry.

If we should adjust to Redis command interface:

# xread(key, start, _end, count = nil)
r.xread('s1', '-', '+')
r.xread('s1', '-', '+', 10)
r.xread('s1', '0-9', '+', 10)

• Pros
  • simple and intuitive
  • consistent for other methods
• Cons
  • we have to specify start and end arguments every time

If we have priority to easy-to-use interface in Ruby:

# xread(key, start = '-', _end = '+', count: nil)
r.xread('s1')
r.xread('s1', count: 3)
r.xread('s1', '0-1')
r.xread('s1', '0-1', '0-9')
r.xread('s1', '0-1', count: 3)

• Pros
  • easy-to-use
• Cons
  • need a few learning cost for the abstraction

I'd say that the latter looks good.