3.34.0 - Update to Swift 6

What's Changed

Update to Swift 6 by @ptoffy in #196

This patch was released by @gwynne

Full Changelog: 3.33.2...3.34.0

3.33.2 - Fix SendableMetatype-related warnings which appear in Swift 6.2

What's Changed

Fix SendableMetatype-related warnings which appear in Swift 6.2 by @gwynne in #193

Title pretty much says it all.

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM

This patch was released by @gwynne

Full Changelog: 3.33.1...3.33.2

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