Hard failure when trying to perform fetchCount or ValueObservation.trackCount on joined query

[Marus]

What did you do?

Was trying to perform a count observation using a QueryInterfaceRequest that involved a join.

What did you expect to happen?

To get a count that matched the query expressed.

What happened instead?

Crash within the GRDB library at https://github.com/groue/GRDB.swift/blob/v3.6.2/GRDB/QueryInterface/QueryInterfaceQuery.swift#L247

Environment

GRDB flavor(s): (GRDB, GRDBCipher, GRDBCustom?) GRDBCipher
GRDB version: 3.6.2
Installation method: (CocoaPods, SPM, manual?) Manual
Xcode version: 10.1
Swift version: 4.2
Platform(s) running GRDB: iOS
macOS version running Xcode: Mojave 10.14.3

Demo Project

Example from a playground I had setup can be seen at https://pastebin.com/arCtuYm2 - the last query in that playground (line 95) would cause the crash. Variants with explicit aliases for both tables (must explicitly alias both) work correctly (even if it may not be the most standard SQL generated for the count query SELECT COUNT(*) FROM (SELECT * FROM ....) - but the variant without explicit table aliases crashes. Since it looks to be crashing on alias! I expect that behind the scenes you generate implicit TableAlias objects if not explicitly done so and for some reason that doesn't happen (correctly) in count variants.

[groue]

Hello @Marus,

Bingo, you have found a bug!

I think I have just fixed it in #490, where some tests for fetchCount on joined queries would crash as well. Those are the 5d9fa76 and 7ff2198 commits, on the way to GRDB 4.

This area of the code has changed quite a bit since GRDB 3.6.2. Inner guts of associations will settle eventually, but this is not quite finished yet. So those commits may not be trivial to backport on the master branch.

Yet I expect those commit to be easily backported to the development branch. Do you fancy have a look? If not, please wait a little bit.

[Marus]

Will try to have a look on the 4.0 branch soon - was planning to try and take a look at that anyway - in particular at the PR for the SQLCipher upgrade.

[groue]

The SQLCipher upgrade (#481) is not ready yet. I'm happy @darrenclark is looking at it because I do not always feel comfortable setting up Xcode targets and build phases, and I know he has deployment constraints that will drive him to a robust solution. I'm sure he will ask for support if he needs some.

Beware SQLCipher 4 is not directly compatible with SQLCipher 3. When it is merged in GRDB 4, you may have to migrate your existing databases: https://discuss.zetetic.net/t/upgrading-to-sqlcipher-4/3283

You can switch to the GRDB-4.0 branch today. I didn't release any beta yet, but it is quite stable. All tests pass unless Travis has a hiccup. Breaking changes are not many, and fixits that help the migration are already there. I don't foresee any other important breaking change until GRDB 4 ships.

Meanwhile, you have found an important bug :-)

[groue]

Superseded by #496