set up tracing for SQLite execution (sqlite3_trace_v2):

[ikusteu]

I've found sqlite3_trace_v2 incredibly useful for debugging an issue I was working on. I've followed the conventions used in rest of the lib*.(js|c) shims and sqlite-api.js and thought this might be a good candidate to include in the project.

Only the SQLITE_TRACE_STMT is currently handled (only one I needed) and I'm opening this as a draft as some thing should be clarified:

• does it even make sense to include this in the project
• should trace shims only be included in demo builds
• should we also derive some data from the prepared statement (does that even make sense) -- currently only the SQL of the statement is reported

I would love to get your thoughts and, if green-lit, impl the support for other trace variants.

Progress:

• create 'libtrace.c' shim (for registering of trace callbacks)
• add JS-side shims for tracing
• TODO: only SQLITE_TRACE_STMT is currently supported: support other trace messages

Checklist

• [x] I grant to recipients of this Project distribution a perpetual, non-exclusive, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, sublicense, and distribute this Contribution and such derivative works.
• [x] I certify that I am legally entitled to grant this license, and that this Contribution contains no content requiring a license from any third party.

[sgbeal]

does it even make sense to include this in the project

FWIW, tracing has proven incredibly useful to me in the past. IMO it definitely makes sense.

[steida]

@sgbeal Hi, does the official SQLite WASM support that API? Thank you

[sgbeal]

@sgbeal Hi, does the official SQLite WASM support that API? Thank you

Of course - debugging without it is too painful.

[rhashimoto]

Thanks for the PR!

I have no inherent objections to adding this to the supported API. I would add it unconditionally, i.e. not restricted by type of build.

What I'd like to see before final review and merge:

• Name the method trace_v2() (not trace()).
• Handle all of the SQLITE_TRACE mask constants.
• The Javascript callback function should accept 4 arguments, just like the C API. They should be the same T, C, P as the C API, plus the appropriately dereferenced X (as you did with the SQL string).
• Add JSDoc and regenerate docs (yarn build-docs).
• Add unit tests. Check that you can enable and disable trace, check that all the modes call back appropriately.

If you have any questions or disagree with anything, let's discuss it. I might say, "My way or else!" but we're not at that point yet.