3.33.1 - Resolve issues breaking Swift Wasm builds for sql-kit

What's Changed

Resolve issues breaking Swift Wasm builds for sql-kit by @scottmarchant in #190

Summary

This PR adds support for compiling sql-kit to wasm using the Swift SDK for WebAssembly.

This PR is part of a larger effort by a company called PassiveLogic to enable broad support for Swift WebAssembly.

Details

• Removed unused NIO dependency in Package.swift. This repo compiles fine without that, but having it breaks wasm compilation.
• Refined scope of exports to be NIOCore instead of the broader NIO.

Notes

• Compiling to wasm requires specific versions of swift-nio. Because swift-nio still doesn’t have wasm targets in it’s CI, the wasm build breaks often. That issue will be resolved soon. Regardless, we don’t want to bump the minimum nio requirement in the manifest, because that would be a breaking change for many using this repo. It is fine to leave the minimum nio requirement as-is. Developers trying to compile for wasm will almost certainly be aware of the issues compiling nio, and will soon have many wasm-compatible versions of nio to select.

Testing done

• Verified unit tests still pass with these changes
• [x]
  …

This patch was released by @gwynne

Full Changelog: 3.33.0...3.33.1

3.33.0 - Add the missing `SQLDatabase.alter(table: any SQLExpression)` method

What's Changed

Add the missing SQLDatabase.alter(table: any SQLExpression) method by @gwynne in #188

Each of the various query builders have overloads on SQLDatabase which accept any SQLExpression parameters, except for SQLAlterTableQueryBuilder. The missing SQLDatabase.alter(table: any SQLExpression) overload is now provided.

Additional changes:

• Fixed several minor issues in the API docs.
• The minimum required Swift version is now 5.10.

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM

This patch was released by @gwynne

Full Changelog: 3.32.0...3.33.0

3.32.0 - Adds multirow insert method

What's Changed

Adds multirow insert method by @NeedleInAJayStack in #153

This adds functionality to do a multi-row inserts with a single values method call.

Previously, to insert multiple rows a user had to call values repeatedly:

db.insert(into: "planets")
    .columns(["name", "color"])
    .values([SQLBind("Jupiter"), SQLBind("orange")])
    .values([SQLBind("Mars"), SQLBind("red")])
    .run()

This was a bit awkward when inserting rows from an array, where an instance of the builder had to be saved off and edited:

let rows: [[SQLExpression]]  = [[...], [...], ...]
let builder = db.insert(into: "planets")
    .columns(["name", "color"])
for row in rows {
    builder.values(row)
}
builder.run()

db.insert(into: "planets")
    .columns(["name", "color"])
    .values([[SQLBind("Jupiter"), SQLBind("orange")], [SQLBind("Mars"), SQLBind("red")]])
    .run()

let rows  = [[...], [...], ...]
db.insert(into: "planets")
    .columns(["name", "color"])
    .values(rows)
    .run()

…

This patch was released by @gwynne

Full Changelog: 3.31.1...3.32.0

3.31.1 - Fix behavior of SQLColumn when "*" is specified as a column name

What's Changed

Fix behavior of SQLColumn when "*" is specified as a column name by @gwynne in #181

This behavior was implemented in SQLUnqualifiedColumnListBuilder but actually belonged in SQLColumn itself. Thanks @ptoffy!

Fixes #180.

This patch was released by @gwynne

Full Changelog: 3.31.0...3.31.1

3.31.0 - Add support for Common Table Expressions

What's Changed

Add support for Common Table Expressions by @gwynne in #179

CTEs (WITH clauses) are now supported by SELECT, INSERT, UPDATE, DELETE, and UNION queries, including subqueries. Test and docs coverage is 100%.

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM

This patch was released by @gwynne

Full Changelog: 3.30.0...3.31.0

3.30.0 - Support the use of unions in subqueries

What's Changed

Support the use of unions in subqueries by @gwynne in #178

Adds support for the use of UNION queries within subqueries. Unfortunately, thanks to iffy design choices on my part in the original SQLUnion implementation, the usage is slightly awkward. Example usage:

try await db.update("foos")
    .set(SQLIdentifier("bar_id"), to: SQLSubquery
        .union { $0
            .column("id")
            .from("bars")
            .where("baz", .notEqual, "bamf")
        }
        .union(all: { $0
            .column("id")
            .from("bars")
            .where("baz", .equal, "bop")
        })
        .finish()
    )
    .run()

This generates the following query:

UPDATE "foos"
SET "bar_id" = (
        SELECT "id" FROM "bars" WHERE "baz" <> "bamf"
    UNION ALL
        SELECT "id" FROM "bars" WHERE "baz" = "bop"
)

Unfortunately, it is not possible to chain .union() when using SQLSubquery.select(_:); the call chain must start with SQLSubquery.union(_:).

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM

This patch was released by @gwynne

Full Changelog: 3.29.3...3.30.0

3.29.3 - Relax minimum dependency version for swift-collections

What's Changed

Relax minimum dependency version for swift-collections by @gwynne in #177

Downstream users of SQLKit who also depend on SwiftPM currently experience a dependency conflict with swift-collections due to SwiftPM’s restrictive allowed version range. Since SQLKit doesn’t actually need the newest swift-collections, we can solve this by simply reducing SQLKit’s minimum required version.

Also removes a spurious dependency on swift-docc-plugin which was accidentally left in place during the 3.29.0 release.

This patch was released by @gwynne

Full Changelog: 3.29.2...3.29.3

3.29.2 - Fix overhaul breakage, part 2

What's Changed

Fix overhaul breakage, part 2 by @gwynne in #176

This solves the source code breakage issue first reported in #175 - shout out and thanks to @NeedleInAJayStack for reporting the problem!

Several preexisting APIs had incorrectly changed from accepting any Encodable to accepting some Encodable, which is source-breaking under some conditions. This restores the original use of any (though it keeps the added Sendable requirement).

Also restores 100% test coverage after the previous fixes.

[!NOTE]
Many APIs which had previously accepted a generic parameter (i.e. <E: Encodable>), most notably in SQLPredicateBuilder, also switched to using some Encodable, but this was not source-breaking; the problem applied only to APIs which originally accepted any Encodable.

Although the changes in this PR are technically themselves source-breaking, since they revert a previous such breakage to its previous state, only a semver-patch bump is necessary.

This patch was released by @gwynne

Full Changelog: 3.29.1...3.29.2

3.29.1 - Fix downstream breakage issues

Fixes some issues that broke building against FluentKit when not using any of the driver packages. Also adds CI to test this scenario.

3.29.0 - Major overhaul of the entire SQLKit package

This is expected to be the last release of SQLKit version 3.

A hopefully complete (but probably not) list of significant changes:

• A massive sweep to add at least minimal documentation to everything in the package.
• 100% test coverage.
• Reorganized the source code layout
• Require Swift 5.8
• Package is now ExistentialAny-compliant
• Numerous poorly-designed APIs have been deprecated. Replacement suggestions are available in all cases.
• 100% Sendable-complaint (zero concurrency warnings).
• SQLDatabaseReportedVersion is now Equatable and Comparable, as it ought to have been from the start.
• Efficiency improvements for the async versions of various APIs.
• SQLQueryEncoder and SQLRowDecoder have been massively overhauled; both are now considerably more flexible and less restrictive.
• SQLBenchmark is now async.
• Numerous ugly assert()s and print()s are now consistently routed through the database's logger instead, and less noisy logging is done.
• Several bits of missing functionality in SQLCreateTrigger are now correctly implemented.
• SQLIdentifier and SQLLiteral.string now automatically escape the appropriate quote characters when serializing.
• Added SQLBetween (x BETWEEN y AND z), SQLQualifiedTable (schema.table), SQLSubquery and SQLSubqueryBuilder, SQLUnqualifiedColumnListBuilder, and SQLAliasedColumnListBuilder.
• SQLPredicateBuilder and SQLSecondaryPredicateBuilder now provide 1-to-1 corresponding APIs for all four variants ("and where", "and having", "or where", "or having").
• Serialization of expressions is now a bit faster across the board.
• SQLInsert and SQLInsertBuilder now support the INSERT ... SELECT syntax.
• SQLQueryFetcher gained a number of convenience APIs for decoding models and single columns. Several builders also gained convenience methods for encoding or decoding of models. (Note that "models" in this usage does NOT refer to Fluent's Model protocol, but rather to any Codable structure.)
• SQLDropBehavior is now used by all builders that support the modifier and respects the current dialect properly.
• SQLCreateIndex now supports index predicates.
• SQLDistinct now serializes correctly.
• Several expressions and queries are now more tolerant of missing configuration when serialized.
• SQLDatabase gained a withSession(_:) API which, when implemented correctly by drivers, allows implementing transactions safely using pure SQLKit (no need for Fluent-level or driver-level intervention).
• SQLColumnConstraintAlgorithm.primaryKey no longer emits incorrect SQL if the active dialect uses NULL as its DEFAULT literal.