1.44.0 - Fully work around MySQL 5.7's lack of the DROP CONSTRAINT statement

What's Changed

Fully work around MySQL 5.7's lack of the DROP CONSTRAINT statement in #575

The work done in #522 added the ability to drop foreign keys when using a MySQL 5.7 database by enabling Fluent to generate the necessary DROP FOREIGN KEY syntax to make up for the old version's lack of the more standard and more flexible DROP CONSTRAINT statement.

However, this still required users to specify the complete and current foreign key constraint definition at the time of deletion so Fluent could work out the correct "normalized" constraint identifier. These changes make it possible to also drop a foreign key constraint by name, requiring only the knowledge that it is, in fact, a foreign key.

Users wishing to drop foreign key constraints by name when using MySQL 5.7 must use the new API provided. Users of other versions of MySQL and other databases may also use the new API, or continue to use the old one.

New APIs added in this release:

• FluentKit.DatabaseSchema.DeleteConstraint.namedForeignKey(_:): Specify a constraint deletion operation using a name and the explicit indication that the constraint to drop is a foreign key.
• FluentKit.SchemaBuilder.deleteForeignKey(name:): Add a constraint deletion for a foreign key with the given name to a schema builder invocation. Identical to deleteConstraint(name:) except on MySQL 5.7.

Fixes #491, vapor/fluent#722. Supersedes #492, #522.

This patch was released by @gwynne.

Full Changelog: 1.43.2...1.44.0

1.43.2 - Add possibility of nested eager load builder to throw

What's Changed

Add possibility of nested eager load builder to throw by @Frizlab in #574

This PR adds the possibility of throwing inside the block that adds nested eager loaders.
I need this because I add eager loading as needed depending on fields (user input), recursively, and I don’t know before it’s too late whether my fields are valid.

As the with functions that are modified are marked as rethrows, this should have no impact on existing code and should not require a major version bump.

This patch was released by @gwynne.

Full Changelog: 1.43.1...1.43.2

1.43.1 - Handle aggregate types a very tiny bit better

This patch was released by @gwynne.

What's Changed

Handle aggregate types a very tiny bit better by @gwynne in #569

This just adds explicit forwarding of the generic Result parameter of the two QueryBuilder.aggregate() variants which weren’t doing so already. It was already being implicitly forwarded due to type inference, but better to do so explicitly.

Also adds notes to the sum() and average() sets of methods warning that the Field.Value return types are not always correct (usually only causes problems with Postgres) and giving the workaround. This is related to #379 and vapor/fluent-postgres-driver#166 …

Reviewers

Thanks to the reviewers for their help:

• @dannflor

Full Changelog: 1.43.0...1.43.1

1.43.0 - Leverage the new support for nested path expressions in SQLKit

This patch was authored and released by @gwynne.

Fluent now takes generic advantage of the new support added by vapor/sql-kit#169 when generating nested subpath expressions.

(Unfortunately, Fluent has never actually invoked this code path to begin with, except via an explicit call to .sql(json:_:), so it doesn't change much at the moment. However, this would always have been a prerequisite to make the real support for it in Fluent's API actually work, so it's a step in the right direction.)

SQLJSONColumnPath is now deprecated in favor of using SQLKit's new SQLNestedSubpathExpression. #572

Explicitly log migration errors

This patch was authored and released by @gwynne.

This ensures errors thrown during migration (both prepare and revert) are fully logged regardless of the behavior of calling code.

Enable using the attached model during pivot editing

This patch was authored and released by @gwynne.

When using Siblings.attach(_:on:_:) with an editing closure, this code would historically crash with a fatal error:

planet.$tags.attach([tag1, tag2], on: database) { pivot in
    print(pivot.tag.name)
    // fatal error: Parent relation not eager loaded, use $ prefix to access: Parent<PlanetTag, Tag>(key: "tag_id")
}

The attach() methods now provide the "right-hand" side of the relation (e.g. left.$siblings.attach([right1, right2])) on the pivot model passed to the editing closure.

Unfortunately, due to limitations of Fluent's design and of property wrappers, it is not possible to also provide the "left-hand" side of the relation, but this is usually less of a concern. The expected use case for having the right-hand model available is to be able to get data from the right-hand model for setting properties of the pivot when attaching an array of siblings in one call. Without this change, this was only possible by matching the right-hand model's ID with one from the original input array. (This being said, this change affects the single-model version of attach() as well, since there is no drawback to doing so.)

This is a solely additive change; it has no effect whatsoever on what data goes into the database, and does not incur any additional speed or memory overhead.

Generate deterministic column ordering in insert and update queries

This patch was authored and released by @gwynne.

This is an updated version of #556 by @rausnitz which updates the generation of INSERT queries to be both deterministic and more performant by eliding pointless repetition of the Fluent -> SQL conversion of the field list.

Additional kudos for @rausnitz for his enthusiasm, which inspired me to take another hard look at the existing logic!

Closes #543

Improved migration performance, better error reporting, and other cleanups

This patch was authored and released by @gwynne.

• FluentError is now CustomDebugStringConvertible
• Fixes #542 by conditionally conforming LoggingOverrideDatabase to SQLDatabase
• Migration no longer spends time checking for prerelease migration names or allocating excess futures
• The Mirror bypass is now enabled for Swift 5.9
• Fluent benchmark suite now has much better error handling
• Fluent benchmarks now run ~5-10% faster (up to 15% for SQL databases)

Update min Swift version to 5.6 and make platform versions consistent

This patch was authored and released by @gwynne.

Allow eager-loading of deleted models

This patch was authored by @tarag and released by @gwynne.

Allows eager-loading of soft-deleted models. For maximum flexibility, choosing whether to load soft-deleted models or not is performed for each relation at each query call.

Usage is as follows: let galaxies = try Galaxy.query(on: self.database).with(\.$stars, withDeleted: true)

Use of default argument value of false requires no change to existing code to keep existing behaviour.

Fixes #375.