feat: @powersync/adapter-sql-js added to support SQL.js #647
Conversation
🦋 Changeset detectedLatest commit: 19c70c7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Chriztiaan
changed the title
Chriztiaan
changed the title
There was a problem hiding this comment.
This looks like a really helpful addition for Expo Go users 👍
I've left some minor comments. One other thing that stands out is that we may want to make it clearer in the readme (or perhaps even by logging something when the database is opened) that this is intended for development only. In particular, I feel like we should warn about this being much slower than the "real" SDK, so that we don't get reports about general PowerSync performance coming from users only trying the SQL.js adapter because it's the easiest one to use.
Chriztiaan
changed the title
| this.writeScheduler = new ControlledExecutor(async (db: SQLJs.Database) => { | ||
| await this.options.persister.writeFile(db.export()); | ||
| }); |
There was a problem hiding this comment.
Looking at the benchmarks, this is probably the cause for slowdown for the in-memory config: This is doing an export of the entire database, right before discarding it. Using a filesystem probably gives better performance because it effectively throttles the exports while waiting for the write, while "in-memory" could trigger an export for every write.
I'd recommend setting persister to null and bypassing this step for the default/in-memory config, instead of creating a no-op persister.
There was a problem hiding this comment.
Will fix in a follow up PR.
…#647) Co-authored-by: Christiaan Landman <[email protected]>
5 participants
Overview
Certain environments have trouble loading PowerSync due to it requiring a SQLite implementation which supports loading our Rust core extension. One of these environments is Expo Go which is a prebuilt app container for Expo apps.
The new
devpackage uses a pure JS implementation of SQLite via SQL.js which has been forked. SQLite and our Rust core extension are compiled to JavaScript via Emscripen there. This pure JS payload can be used in environments such as Expo Go.Outstanding work
SQL.js operates in memory. We can persist the entire DB to disk on commit though. This has not yet been implemented for RN.Added Expo persister in the adapter-sql-js adapter's README.mdThis currently builds SQL.js in the monorepo. This requires toolchains which we should not expect all users of the monorepo to have present. We could fallback to prebuilt assets in such cases.This build was moved out to the SQL.js fork.adapter-sql-jspackage. The adapter-sql-js package is no longer re-exported byreact-nativeas that affected the bundle size for production build.Demo
ExpoGo2.mp4
Benchmarks
Tested 1000 separate list insertions, PowerSync not connected. Haven't been able to understand why the Expo file persister version is faster than the in-memory persister.
