GRDB 6 missing DatabasePool/DatabaseQueue interchangeability

[freak4pc]

What did you do?

I upgraded from GRDB 5.26.0 to 6.27.0, mostly seamlessly :)

What did you expect to happen?

We have some wrapper code that keeps the databaseWriter in following property:

var dbWriter: any GRDB.DatabaseWriter

Then, in our production code we use a DatabasePool, but in tests we would sometimes swap to an in-memory DatabaseQueue.

This worked fine in GRDB 5 and I hoped it would behave the same in 6.

What happened instead?

The compiler complains that certain pieces like ValueObservation or DatabaseMigrator expect a some DatabaseWriter and not any DatabaseWriter, like so:

Environment

GRDB flavor(s): GRDB
GRDB version: 6.27.0
Installation method: SPM over Tuist
Xcode version: 15.3
Swift version: 5.10
Platform(s) running GRDB: iOS
macOS version running Xcode: Sonoma

Demo Project

Doesn't seem needed in this case

[groue]

Thank you @freak4pc for reporting this issue.

It looks that some auditing should be done indeed. Those are APIs I rarely use myself in this way, so I did not notice the problem.

I'll make an exhaustive list of methods that accept a generic DatabaseWriter or Reader.

I don't quite get why SE-0352 does not apply, though.

In the linked proposal text, search for "In the existing language, one could implement a shim..." The described technique will give you the needed workaround until GRDB7 can do what is needed so that no one faces the same issue as you do.

[freak4pc]

This section even more explicitly states you should be able to move from any to some and back, any chance this could be a bug?

https://github.com/apple/swift-evolution/blob/main/proposals/0352-implicit-open-existentials.md#moving-between-any-and-some

[groue]

This section even more explicitly states you should be able to move from any to some and back, any chance this could be a bug?

https://github.com/apple/swift-evolution/blob/main/proposals/0352-implicit-open-existentials.md#moving-between-any-and-some

I'll open a Github issue in the Swift repo if something does not behave as described by the proposal, yes. I'll need a closer look. Meanwhile, we just need GRDB users to be able to use any DatabaseWriter freely, since this is how we can use a pool in the app, and a queue in tests and previews. That's what's important.

(I'm late in my answer because I was in vacations 😎)