Skip to content

Releases: vapor/sql-kit

Add support for specifying a query logging level at the SQLKit layer

06 May 08:43
054ea50
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

Add SQLDatabase.queryLogLevel protocol requirement, defaulting to .debug for databases which don't implement it. Each individual driver must implement support for this logging. This corresponds to the sqlLogLevel configuration in FluentPostgresDriver and is the first step in normalizing support for it at the PostgresKit/MySQLKit/SQLiteKit layer.

Update min Swift version to 5.6 and make platform versions consistent

14 Apr 00:57
d547122
Compare
Choose a tag to compare

Make SQLList's properties mutable

03 Feb 13:57
fcc29f5
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

Improves consistency with other SQLKit types (and is incidentally convenient for Fluent).

Support += operator for SQLQueryString.

15 Nov 11:47
dcf10a0
Compare
Choose a tag to compare
This patch was authored by @maciejtrybilo and released by @gwynne.

Very simple change to support the += operator for appending SQLQueryStrings.

Bump minimum Swift version to 5.5

15 Nov 11:12
e309850
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

Also syncs up CI with the latest refinements.

Add support for varying syntax of SELECT locking clauses.

02 Aug 21:00
3c5413a
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

The FOR SHARE syntax previously provided by adding .for(.share) to a SELECT query is specific to PostgreSQL. This update allows each database driver to specify the correct syntax for locking clauses - or to signal that it doesn't implement that functionality - via its SQLDialect. The default is to assume locking clauses are not supported.

Because new public API is added to SQLStatement and SQLDialect, this update is semver-minor.

PR for MySQL support: vapor/mysql-kit#310
PR for PostgreSQL support: vapor/postgres-kit#230
PR for SQLite support: <not required, SQLite does not support locking clauses>

Adds `LIMIT`, `OFFSET` and `ORDER BY` to Union results

01 Aug 09:32
0df1585
Compare
Choose a tag to compare
This patch was authored by @NeedleInAJayStack and released by @gwynne.

Previously it was not easy to do pagination on the result of SELECT ... UNION queries. For example:

(SELECT * FROM "Table" WHERE "name" = 'first thing')
UNION ALL
(SELECT * FROM "Zone" WHERE "name" = 'second thing')
LIMIT 5
OFFSET 3
ORDER BY "name"

This pull request adds LIMIT, OFFSET, and ORDER BY functionality to the SQLUnion/SQLUnionBuilder, primarily by copying over the SQLSelect and SQLSubqueryClauseBuilder implementations.

I also have a protocol-based approach that reduces code copying but it comes with it's own smells. I'm happy to elaborate if desired.

UNION handles single entry

25 Jul 10:22
b7901df
Compare
Choose a tag to compare
This patch was authored by @NeedleInAJayStack and released by @gwynne.

This PR simplifies dynamically building UNION statements.

To be specific, it loosens the restriction that a SQLUnion must contain multiple select statements. While this is common usage, it makes building up UNIONs in client code difficult. For example, building up a UNION in a for loop is awkward right now:

let ids = [1, 2, 3, ...]
guard let firstId = ids.first else { ... }

// Must manually short-circuit as a SQLSelectBuilder
guard ids.count > 1 else {
    return sql.select.column("id").from("t1").where("id", .equals, firstId).all()
}
let unionBuilder = sql.union { select in
    select.column("id").from("t1").where("id", .equals, firstId)
}
for id in ids[1..<ids.count] {
    unionBuilder.union(all: { select in
        select.column("id").from("t1").where("id", .equals, id)
    })
}
return unionBuilder.all()

This PR removes the need for the commented guard in the code above. It also improves code safety by removing a runtime fatal error condition.

Add ability for SQLKit drivers to expose version numbers

22 Jul 05:13
3e166a3
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

Also fills in some missing documentation.

Add support for MySQL's DROP INDEX syntax

28 Apr 11:57
89b0a0a
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

MySQL's version of DROP INDEX differs from PostgreSQL's in that it requires an ON <table name> clause in order to identify the index to drop, since MySQL treats indexes as table-level objects rather than schema-level. This PR adds support for optionally specifying the table name.

Also deprecates SQLDataType.type(_:), which should never have been public - it is a utility method used in one place by a single test case; its behavior is only valid in PostgreSQL, and even then only for custom-typed enums, but its name and placement give no hint of this to callers. Since it is public API, it can not be summarily removed without a semver-major break, but we can at least remove the single call site and discourage any further use.

Also updates the CI workflows as per the usual in my PRs 🙂.

Note: semver-minor not only due to the new public API on SQLDropIndexBuilder but also because the deprecation of a public API is, while not source-breaking, annoying for anyone who actually used it.