Skip to content

RediStack 2.0.0 Alpha 1

Pre-release
Pre-release
Compare
Choose a tag to compare
@Mordil Mordil released this 22 Feb 18:58
· 55 commits to master since this release
79d0fd8

API Docs are always available at docs.redistack.info

RedisCommand has been repurposed from the RedisCommandHandler.OutboundIn type to now a generic general-purpose value representation of a given command keyword, it's argument payload, and its expected deserialized result type.

These changes are primarily driven by the desire to support MULTI commands, as outlined in #88.

In RediStack 1.x, commands were inseparable from the method extension that generated them, and they were all eagerly executed in both sending and receiving.

By turning them into a lightweight value representation, a command can be delayed in being sent or its response in being deserialized.

As such, the following notable changes have happened:

  • RedisClient.send now accepts just a single RedisCommand instance, but otherwise behaves as before: it will deserialize the response to the RedisCommand.ResultType for you
  • RedisCommandHandler.OutboundIn is now a tuple of (RESPValue, EventLoopPromise<RESPValue>) with the first element being the fully serialized command to be sent.
  • All command extension methods on RedisClient are now static factory methods on RedisCommand
    • The name of the static factory extension will match the name as used by Redis itself
    • In some cases, the previous extension methods on RedisClient still exist, but are just convenience methods for calling the appropriate RedisCommand factory method.
      • There is no established rule on when these extensions will be supported. The ones that remain are ones that tend to make sense from an English prose perspective of relationship of the action being invoked and the client

        For example RedisClient.publish(_:to:) still exists, because RedisClient.publish(message, to: channel) reads a little better than RedisClient.send(.publish(message, to: channel)), since the client itself is doing the publishing and there is an implicit relationship between clients and PubSub channels.

        As a counter-example, RedisClient.linsert(_:into:before:) is now only available as RedisClient.send(.linsert(_:into:before:)) because it's a general command with no clear relationship between the command being invoked and the specific client doing the invocation.

Major

  • Swift 5.2 is now the minimum supported Swift version (b148491)
  • RedisCommand and the extension methods on RedisClient have seen a significant refactor with no deprecation support to be provided !144
    • As a consequence of the changes, RedisComandHandler.OutboundIn is now (RESPValue, EventLoopPromise<RESPValue>)

Minor

Several pieces of API have been deprecated. They will be removed in the next major version.

  • RedisLifetimeKey has been moved and renamed to RedisKey.Lifetime !143
  • RedisLifetimeKey.Lifetime has been renamed to RedisKey.Lifetime.Duration !143
  • RedisCommand.flushall extension has been added !144

Misc

  • The README has been updated to indicate the in-development status of 2.0.0 (40d521c)
    • Historical version information, such as CI testing is available as extra details in the README (ba35a1f)
  • Swift 5.4 CI testing has been added (e2e8890)