GitLab

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

Motivation:

`RedisKeyLifetime` already has "RedisKey" as a prefix so it naturally fits as a nested type.

Modifications:

- Change: `RedisKeyLifetime` to be nested in `RedisKey` and named `Lifetime`
- Rename: `RedisKeyLifetime.Lifetime` to `Duration`
- Deprecate: `RedisKeyLifetime` and the nested type `Lifetime`

Result:

The global namespace is a little less cluttered with the types falling naturally where they already are.

Motivation:

One of the great features of Redis is being able to subscribe and receive messages published to specific channels
as a way of acting as a message queue for processing jobs.

PubSub requires a specific understanding of the connection model that can only be implemented directly in this library.

Modifications:

- Add: `RedisPubSubHandler` to sit in front of `RedisCommandHandler` to manage subscription callbacks and Redis registration
- Add: `publish` and the `pubsub` commands
- Add: `addPubSubHandler` extension to `NIO.Channel`
- Add: Type-safe String wrapper of `RedisChannelName` for PubSub methods
- Add: `pubsubSubscriptionNotFound` error case
- Add: `isSubscribed` property to `RedisConnection`
- Add: `availableConnectionCount` and `leasedConnectionCount` properties to `RedisConnectionPool`
- Add: Metrics for PubSub
- Add: `makeNewPool` factory method to `RedisConnectionPoolIntegrationTestCase`
- Change: `RedisClient` to require methods for PubSub management, as they are intrinsicly tied to the client's connection model
- Change: Parsing of `PING` response for handling special case in PubSub mode
- Rename: `ActiveConnectionGauge` to `RedisMetrics.IncrementalGauge`

Result:

Developers will now be able to use Redis in PubSub mode with both connections and pools.

This resolves #6

Motivation:

As originally pointed out in #48, the `map` prefix alone is not enough context into what the method actually does.

Since it fails the future, and isn't a mapping function, the name should reflect this.

But, this method as-is currently provides little value outside of the client context, so it should not be `public`.

If users provide an adequate use case for having it outside of the package, then it can be made public again.

Modifications:

- Rename: ELF where Value == RESPValue extension `map` to `tryConverting`
- Change: `tryConverting` from public to internal

Result:

A "problematic" method should no longer be available for API users to hurt themselves with.

Motivation:

The SETEX and PSETEX commands are missing.

Modifications:

- Add SETEX command
- Add PSETEX command
- Add integration tests

Result:

Users can atomically set a key with an expire

Motivation:

SET has a range of options for setting expirations and conditionally
setting a value.

Modification:

- Add another `set` function with a range of options. Options are
  modelled as `struct`s backed by private `enum`s to allow additional
  options to be added without breaking API.
- Added tests

Result:

Options may be specified with `set`, and resolves #67

Motivation:

The SETNX command is missing.

Modifications:

- Add SETNX command
- Add integration test

Result:

Users can set a key only if it does not already exist

Motivation:

The TTL and PTTL commands are missing.

Modifications:

- Add TTL and PTTL commands
- Add integration tests

Result:

- Users can query the ttl in seconds or milliseconds of a key

Motivation:

The EXISTS command was missing.

Modifications:

- Add 'EXISTS' to basic commands
- Add integration tests

Result:

The existence of a key can be checked.

Motivation:

`RESPValue` exposes a fair amount of complexity on how to intialize a single instance with the various overloads.

This aims to simplify the complexity for developers by providing a single initializer and relying on `RESPValueConvertible` to handle the complexities.

In addition, the Swift complier synthesizes a lot of default conformances that `RedisKey` has manually written, which is just unnecessary code.

Modifications:

- Rename: `RESPValue.init(_:)` to `RESPValue.init(from:)`
- Change: `RESPValue.init` `String?` and `FixedWidthInteger` overloads from `public` to `internal`
- Remove: Unnecessary code for various protocol conformances for `RedisKey`

Result:

Developers should have a direct and guided way of making instances of `RESPValue`

Motivation:

It was noticed that many of the commands are cumbersome to use with boilerplate type casting for each use that can be simplified within the library
by doing type conversion before returning the value to an end user.

Modifications:

Many APIs that return a `RESPValue` now have overloads to provide a `RESPValueConvertible` type that the value will be turned into before being returned.

For a few APIs that returned `RESPValue`, they did so as an Optional. Those APIs have been changed to always provide a `RESPValue` and return `.null` in cases where `nil` was returned.

In addition, the `@inlinable` attribute has been removed from any non-generic command API.

Result:

Developers should have less code boilerplate for turning values from `RESPValue` to their desired type with many commands.

Motivation:

The SortedSet and List range commands (LTRIM, LRANGE, ZRANGE, etc.) are stringly-based and not flexible with Swift syntax.

Modifications:

- Add overloads of LTRIM that support the gambit of Range Standard Library types
- Rework LRANGE to mirror LTRIM method signatures
- Rework ZScore Range based commands to be more type-safe with `RedisZScoreBound` enum
- Rework ZLex Range based commands to be more type-safe with `RedisZLexBound` enum
- Rework ZCOUNT, ZLEXCOUNT, ZRANGE, ZREVRANGE, ZREMRANGEBYLEX, ZREMRANGEBYRANK, ZREMRANGEBYSCORE methods to be more type-safe and support Swift Range syntax

Result:

Working with SortedSet ranges should be much more type safe, and expressive with Swift's Range syntax.

Motivation:

While reviewing the API, the current design does not read well, and still has room for misunderstanding the actual end result of a ZADD operation.

Modifications:

- Rename `RedisSortedSetAddOption` to `RedisZaddInsertBehavior` and update cases to match desired use site syntax.
- Add `RedisZaddReturnBehavior` enum to define how `zadd` should calculate the return value.
- Update `zadd` and its overloads to support the two new enums in the form of `zadd(_:to:inserting:returning:)`

Result:

The more "Swifty" API will make it much more clear to developers at the call site what the actual behavior of the ZADD command will be.

Motivation:

The goal is to have a strong-typed API for type-safety in arbitrary values, such as trying to use
Int to represent time - as '3' could mean any unit of time, leaving many places for errors and bugs.

Modifications:

Switch all current APIs that accept a `timeout` argument to use `NIO.TimeAmount` instead of a plain `Int`.

Result:

Developers will have an easier time reasoning about their own code as to what values might mean when working with
timeouts in Redis APIs.

Motivation:

Inspired by Swift by Sundell's article on type-safe identifers, the goal of this commit is to have the compiler
assist in preventing incorrect Redis key values from being used in API calls.

See https://www.swiftbysundell.com/articles/type-safe-identifiers-in-swift/ for the inspiration.

Modifications:

- Add new `RedisKey` struct that wraps around a single `String` value that conforms to several expected protocols
  (Hashable, Comparable, Codable, etc.)
- Change all command APIs to require `RedisKey` rather than plain strings

Result:

When encountering an API requiring a RedisKey, it should be much more apparant at the use site what form a value should take.

Motivation:

The library provides command implementations for almost every single Redis command, authorize is no different.

Modifications:

Add `authorize(with:)` command method on `RedisClient`
Replace the implementation in `RedisConnection.connect(...)`

Result:

Developers should now have independent access to the `AUTH` Redis command on `RedisClient` implementations.

Motivation:

For ergonomics, users sometimes want to provide arguments as a variadic list rather than an array.

Modifications:

- Add variadic overloads for almost all methods that accept lists of homogenous types

Result:

Users should have more flexibility in the way arguments are passed to command methods

Motivation:

It is wrong to always assume that a GET operation is expecting a String response type, as users may be storing other types of data.

Modifications:

- Add `get` generic method with a constraint for types of `RESPValueConvertible` to convert values to the user desired type
- Change existing `get` method to specialize the generic overload
- Fix incorrect doc block regarding the ELF failure condition

Result:

Users should now be able to specialize the return type of a "GET" command

Motivation:

Issue #60 called for improving the type safety of the options available for the `zadd` command, and MR !70 made some great headway, but attempted to cram too much into a single enum.

Modifications:

- Break the `RedisSortedSetAddOption.returnChangedCount` value into an additional boolean param

Result:

Using `zadd` should now be more straight forward, while being type safe.