Update sqlite3 and sqlite3_web, deprecate flush parameter#153
Open
simolus3 wants to merge 3 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This updates
sqlite3andsqlite3_webdependencies. We benefit from two updates here:sqlite3version3.3.0andsqlite3_webversion0.9.3improve IndexedDB support. Instead of starting an IndexedDB transaction asynchronously after the first write to the VFS, the packages now batch writes until the end of auseLockcall before commiting them in a single transaction. This improves reliability (there's no way we end up committing in the middle of a SQLite write), performance (single transaction instead of one per file), and allows us to deprecate theflushoption here (since that is now fast enough to happen unconditionally).3.4.0(or0.9.4ofsqlite3_web) improve how values are bound to prepared statements and how they're read from SQLite. Previously, we'd map them to Dart objects as an intermediate layer before converting them to JavaScript values. Now, we can directly map JavaScript values to parameters and result columns to JavaScript. This fixes an (arguably obscure) type issue around numeric types. Because the worker is compiled to JavaScript, it can't tell3(an integer) apart from3.0(a double), but SQLite sure can (throughsqlite3_bind_doubleandsqlite3_bind_int64). By letting clients tag the value they intended to set and using that to bind values without an intermediate Dartnumobject, we can now preserve these number types correctly. This is only observable fromdart2wasm-compiled apps, or from Kotlin once we start using the Dart web worker there.