Skip to content

Refactor RedisCommand into a general use object

Nathan Harris requested to merge rework-commands into master

Motivation:

RediStack today represents a command as a temporary object for the purpose of writing to the channel.

While it is useful to have an object for that purpose, commands handled in this way require immediate execution and aren't available for other purposes.

Commands can serve a better purpose as a lightweight object to support delayed execution, so that pipeling as described in issue #63 could be possible.

Modifications:

  • Add: get overloads for JSON codable interaction on RedisClient
  • Add: New RedisZRangeResultOption type for better interactions with zrange operations that can optionally return scores
  • Add: New RedisHashFieldKey for type-safety when working with Hash field keys much like RedisKey
  • Change: A few API types from enums to structs for library evolution
  • Change: RedisCommandHandler to operate on a tuple of RESPValue, EventLoopPromise<RESPValue> rather than RedisCommand
  • Change: RedisCommand to be a generic struct with the keyword, arguments, and a transform closure to defer execution
  • Change: Almost all RedisClient command extensions to be factory methods on RedisCommand instead
  • Change: Many response types to be optional to avoid developers having to do isNull checks on their own
  • Change: RedisClient.send(command:arguments:) to be generic with send(_:) as the signature
  • Rename: RedisClient extensions for scan methods to be more discoverable and legible as scanHashField, etc.

Result:

It should be easier to support a clean pipelining API with deferred command execution, with extensions being easier for 2nd party developers, and the maintenance overhead of all of the command extensions should be a little lighter when it comes to changing HOW commands are sent such as adding a context parameter

Merge request reports