Grdb.swift: Should FTS5 be enabled by default?

[dinhvh]

I saw a previous GitHub issue claiming that sqlite on macOS 10.13 ships with FTS5.
I assume it's been enabled on iOS around the same time.

Should we enable FTS5 by default now?

[groue]

Hello @dinhvh :-)

The requirements in the README say:

iOS 10.0+ / macOS 10.10+ / tvOS 9.0+ / watchOS 2.0+

So, no, FTS5 can not be enabled by default, unfortunately.

Now of course, I will favorably welcome any pull request which extends the current documentation for enabling FTS5. We currently have documentation for CocoaPods, SQLCipher, and custom SQLite builds. We only miss support for SPM, dont we?

[groue]

I recommend looking at https://github.com/groue/GRDB.swift/network, because several recent forks are exactly about FTS5 and SPM. I did not have a close look, but I think SPM makes it uneasy to have distinct platform requirements per target. If this is exact, our limit here is SPM itself. This may explain why nobody has submitted a pull request yet.

[groue]

Last bit of thinking: it should be possible to duplicate all FTS5-related code. One part is exposed to Apple systems and guarded by @available checks. Other parts are exposed to custom SQLite builds and SQLCipher, guarded by some #if. But now we're really fighting the language, which is 😭 unable to import #define from C headers... Oh life would be so much easier.

We really are in the worst corner of Swift-C interrop. I don't know if it's a good idea to introduce awful workarounds, when maybe some pressure on Swift evolution could make marvels. I never took the time to gather what I learned here in order to build some kind of pitch.

[groue]

No news is good news. I close this issue, since nobody is busy looking at it.

[dinhvh]

I shamelessly went with FTS3. It was probably good enough.

[andyj-at-aspin]

Can I add to this closed issue, Gwendal? I wanted to use FTS5 so I could create my own tokeniser and tokenise all sub-strings of each term - so allowing matches inside each original term starting at the 'n'th character - and am committed to SPM. I've done exactly what you mention below and have a fork ready for a pull request. I recognise it's unwieldy but it does allows FTS5 from a straight SPM inclusion - or any other method as long as the target OS version supports it.

Whether you'll accept the code duplication is another matter. Please let me know and I'll create a pull request.

Last bit of thinking: it should be possible to _duplicate_ all FTS5-related code. One part is exposed to Apple systems and guarded by @available checks. Other parts are exposed to custom SQLite builds and SQLCipher, guarded by some #if. But now we're really fighting the language, which is 😭 unable to import #define from C headers... Oh life would be so much easier.

We really are in the worst corner of Swift-C interrop. I don't know if it's a good idea to introduce awful workarounds, when maybe some pressure on Swift evolution could make marvels. I never took the time to gather what I learned here in order to build some kind of pitch.

[groue]

Thanks you @andyj-at-aspin. I won't merge this amount of duplicated declarations. Now more than ever, I think that the proper action is to make the language evolve, by pitching something on https://forums.swift.org