sqlite3_trace() deprecated in SQLite 3.14.0

[swiftlyfalling]

sqlite3_trace() has been deprecated in SQLite 3.14.0, in lieu of sqlite3_trace_v2()

Added two new C-language interfaces: sqlite3_expanded_sql() and sqlite3_trace_v2(). These new interfaces subsume the functions of sqlite3_trace() and sqlite3_profile() which are now deprecated.

This function is used in Database.setupTrace() in Database.swift.

Just a heads-up.

[groue]

Yes @swiftlyfalling, thanks for the heads-up.

I don't know yet what sqlite3_trace_v2 adds, though.

[groue]

Listen, @swiftlyfalling, I'd rather close this issue for now. It does not reveal any real issue, and solving it requires using swift availability checks in order to:

• call the deprecated method on systems that do not ship with the new sqlite
• expose new logging facilities only on systems that ship with the new sqlite

That's a lot of work for a benefit that I don't clearly see yet. Let's wait for a real feature request.

[swiftlyfalling]

Makes sense. It looks like even if SQLite is compiled with the flag SQLITE_OMIT_DEPRECATED, sqlite3_trace() still exists (as of 3.14.1 - this could change in the future).

[adamek314]

Still shows up as a warning.

[groue]

Comments above still stand as well.

[groue]

Some news: this warning is emitted when GRDB uses the SQLite version that ships with iOS or macOS. That is because GRDB has to use the deprecated sqlite_trace() function in order to support iOS 8.0 and OSX 10.9.

GRDBCustom (which uses custom SQLite builds) no longer emits this warning since ec65335.

When GRDB upgrades its deployment targets to iOS 10.0 and OSX 10.12 (which won't happen until a long time), this warning will disappear. We can also hope that Apple enhances the sqlite3.h that ships with its SDKs.

[gennaios]

Hello groue, I hope you don't mind a comment relating to sqlite3_trace in this issue rather than a new one.

Would it be possible to remove use of it? As GRDB now I believe requires a SQLite as well as iOS/macOS versions where such is deprecated and I think that also include sqlite3_trace2, it seems possible to remove. Such would allow for an additional SQLite compile option to remove deprecated features. I've tried such and the only complaint is for sqlite3_trace. The option is mentioned as a possible, though perhaps small or tiny, performance improvement. From what I recall, it may also be one of the recommended compile options.

[groue]

Hello @gennaios,

Would it be possible to remove use of it?

No. Some systems listed as supported do not have sqlite3_trace_v2 (tvOS 9.0 for example, maybe others as well - I did not make a comprehensive check).

I've tried such and the only complaint is for sqlite3_trace.

This sentence is not clear. What do you want to avoid, and in which scenario, exactly?

[gennaios]

My mistake. It has been a while since I’ve looked at the compile-options. It was listed as recommended though not one that has any performance impact.

SQLITE_OMIT_DEPRECATED. Omitting deprecated interfaces and features will not help SQLite to run any faster. It will reduce the library footprint, however. And it is the right thing to do.

https://www.sqlite.org/compile.html

[groue]

Maybe I miss something. When GRDB links to a custom SQLite builds, sqlite3_trace is not used at all, not even compiled. So setting SQLITE_OMIT_DEPRECATED should not create any problem.