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.

3.28.0 - Add support for nested subpath (JSON) expressions

This patch was authored and released by @gwynne.

Adds a new (defaulted) SQLDialect method for correctly generating JSON subpath syntax on a per-dialect basis. Add SQLNestedSubpathExpression to enable actually invoking the method.

Major codebase cleanup

This patch was authored and released by @gwynne.

A massive pass across the entirety of SQLKit, doing the following:

• Fix, correct, clarify, add, and streamline documentation comments across the board.
• Use any in all places it should appear.
• Normalize coding style (esp. omitting unneeded returns and consistent use of self.).
• Add @inlinable and @usableFromInline to a significant amount of the API, hopefully improving performance.
• Fix some minor copy-pasta bugs, mostly in SQLCreateTrigger.
• Deprecate use of non-trivial raw SQL strings outside of SQLQueryString or SQLRaw.