Gwynne Raskind

@madsodgaard Ideally, I'd prefer to add functionality to FluentKit to express what you're currently using SQL for, rather than encouraging breaking the abstraction. In practice, of course there's only so...

This is technically semver-patch, but the change in behavior of thrown decoding errors could easily break existing error recovery logic, especially given how long this has been broken. Also people...

I'm actually not sure if you would hit the `fatalError()` path that way as things stand... if so then it's not a breaking change.

`DELETE` queries which require joins (also known as multi-table delete) are not currently supported by Fluent (or even by SQLKit), due to the lack of consistent support or syntax between...

Some notes: - This can be mitigated with `.fields(for: PrimaryModel.self)` or individual `.field()` invocations - The default behavior of returning all joined columns can not be changed without breaking compatibility...

The underlying problem is the same one that makes handling enums so awkward in Fluent to begin with - Fluent doesn't really have any facility for correctly dealing with database-typed...

The issue is further exacerbated by Swift generating incorrect decoding logic when it encounters property wrappers with optional wrapped values, always decoding the corresponding coding key unconditionally. As most encoders...

Additional note: As with some other outstanding concerns around property wrappers, the formalization of API vs. implementation detail property wrappers in SE-0293 theoretically cleared the path to a solution, but...

I've been hesitant to lift support for locking clauses from SQLKit to FluentKit, given the lack of direct control over various behaviors and additional queries Fluent performs on its own...

@gregcotten It is already possible to use the locking clauses by dropping down to SQLKit and issuing queries from there. (I'm planning when I get a chance to upstream a...