Motivation:
SwiftPM as of Swift 5.2 introduces a new package dependency graph and package description that makes the current naming of RediStack awkward to pull in.
Modifications:
- Change: Package.name to be "RediStack"
The git repo will be renamed to "mordil/redistack" in addition to this change.
Result:
Fixes#72 and makes it seamless to pull in RediStack as a Swift package dependency.
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:
It it pretty common as a developer when working with connections and "database" clients to want to know
if the connection is currently open before doing any work.
Modifications:
Add `var isConnected: Bool { get }` requirement to the `RedisClient` protocol
Result:
Developers should now have access to the connectivity state of any `RedisClient`
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:
Logging is more dynamic in real world usage than the current static heavy API allows.
Users generally want to be capable of updating connection logger metadata to attach dynamic properties such as an HTTP request ID for log tracing.
Modifications:
- Move all logs to `RedisConnection`
- Add `id: UUID` property to `RedisConnection`
- Add `logging` property and `setLogging(to:)` method requirements to `RedisClient`
- Add chainable `logging(to:)` method extension to `RedisClient`
- Add additional `trace` log statements to `RedisConnection`
- Change when `RedisConnection.init` logging and metric calls are made
- Change some `debug` log statements to `trace in `RedisConnection`
Result:
Users should have infinitely more flexibility in how RedisConnection, and RedisClient implementations in general, behave in regards to logging.
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:
The assertions in `errorCaught(context:error:)` and `channelRead(context:data:)` are holdovers from when SwiftLog was not integrated into the package. The conditions where they were triggered are safely handled in other ways, so the asserts are not guarding against undefined behavior or bad app state.
Modifications:
Remove the two asserts regarding the `RedisCommandHandler.commandResponseQueue` to rely on Logging to bubble up errors to the user.
Result:
Debug builds using RediStack should not encounter unexpected assertions and should rely on other, better, error handling.
This contributes to issue #65
Motivation:
After enabling the thread sanitizer during testing, a data race with the `activeConnectionCount` in `RedisMetrics` was caught due to changing a primitive `Int` across threads.
Modifications:
Add a specialized class `ActiveConnectionGauge` to wrap the semantics of the `activeConnectionCount` with an `Atomic<Int>` property.
Result:
No data races should occur with the `RedisMetrics` subsystem.
Motivation:
Now that SwiftPM with 5.1 supports Linux thread sanitizers, we should run this as part of the normal test pass to catch threading issues.
Modifications:
Add `--sanitize=thread` argument to `swift test` commands for any job that runs Swift >=5.1.
Result:
More bugs should be caught as soon as possible now that thread races are being monitored.
Motivation:
With the release of Swift 5.1, the official docker containers are available for both 16.04 and 18.04 of Linux - so the test matrix should include them.
Modifications:
- Add new 5.1 jobs for 18.04 linux and change 16.04 5.1 jobs to use the official docker images.
- Update the README to capture the changes
Result:
The number of configurations the library is tested against should be as wide as possible for regular interval testing passes.
Motivation:
While working to add more test coverage with `RESPTranslator`, it was made apparent that a `.bulkString(.none)` is impossible to create directly with the `RESPValue` initializers, even though it is a reasonable possibility.
Additionally, forcing all integer types to have to be stored in an `Int` is unnecessarily restrictive.
Modifications:
- Change `RESPValue.init(bulk:)` initializers to accept `Optional` instances
- Change `RESPValue.init(bulk:)` for `Int` initializer to be generic on `FixedWidthInteger`
Result:
Converting types to and from `RESPValue` should be more bi-directional and seamless.
Motivation:
Diagnostics for why `.bulkString` parses might fail were weak, and edge cases fell through gaps in coverage were found.
Modifications:
Added new cases to `RESPTranslator.ParsingError` for `.bulkString` parsing with additional test coverage.
Result:
Users should have better diagnostics for bogus data or failed parsing state.
Motivation:
While working on issue #56, it was forgotten to add the new test cases to the linux manifest file.
Modifications:
Update the linux manifests to include all current unit tests
Result:
All written unit tests should be ran on Linux
Motivation:
MRs take unnecessarily too long to have completed pipelines with "redundant" builds happening in sequence.
The entire stage of building in release is an additional QA layer that can happen on merges into master, but for MRs are just added CPU cycles.
While it's useful to ensure that building in release is possible, we will get almost all build failures from the test stage, and the most important checks are the unit and integration tests.
Modifications:
Change the ordering of build vs. test, as well as only running "build in release" jobs on the master branch.
Result:
MRs should be able to be merged sooner as CI pipelines take less time to run.
Nathan Harris