3.35.0 - Allow generic upsert conflict resolutions

What's Changed

Allow generic upsert conflict resolutions by @gwynne in #197

It is now possible to specify an SQLInsert’s conflictStrategy as a generic SQLExpression, using the new genericConflictStrategy property, around which conflictStrategy is now a wrapper. All existing code will continue to work unchanged. This is intended for use by extensions to SQLKit which, e.g. provide access to database-specific conflict resolution syntax.

Also updates the docs to resolve lots of warnings and some broken links.

Reviewers

Thanks to the reviewers for their help:

• @ptoffy

This patch was released by @gwynne

Full Changelog: 3.34.0...3.35.0

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