Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

native sqlite extension #46

Open
carlsverre opened this issue Jan 17, 2024 · 2 comments
Open

native sqlite extension #46

carlsverre opened this issue Jan 17, 2024 · 2 comments
Assignees
Labels

Comments

@carlsverre
Copy link
Contributor

Currently SQLSync wraps SQLite in order to carefully control how SQLite behaves and improve the user experience of using SQLSync. But this makes SQLSync harder to port to new SQLite environments.

This feature request is to build a version of SQLSync that can run entirely within SQLite as a native extension.

Things to figure out:

  • What does the mutation/reducer layers look like? If the reducer continues to be Wasm, it can run internally; alternatively SQLSync can somehow call out to the host to run mutations when needed.
  • How easy is it for SQLSync to have a private timelines table if it's entirely inside the SQLite engine?
  • Will need to add some pragmas/custom functions to inspect and control SQLSync from the host
@carlsverre carlsverre self-assigned this Jan 17, 2024
@carlsverre
Copy link
Contributor Author

carlsverre commented Jan 18, 2024

The initial goal is to just get a loadable extension that works with the native run-time loadable extension system. This will ideally make SQLSync work with the largest amount of targets.

Then, work can begin on making it easier for folks running in the browser to use SQLite extensions. Some projects/prior work that is relevant to this effort:

It would be very cool to look into dynamically loading extensions at runtime via Wasm dynlinking, and ideally working with https://github.com/nalgeon/sqlean to support a large library of extensions.

@carlsverre
Copy link
Contributor Author

Research notes as of Jan 24 2024

sqlite-loadable-rs

Just do it manually?

  • Current SQLSync code already knows how to register itself as a VFS
  • The only missing pieces are: compiling to a shared module and supporting the SQLite extension registration function calls
  • I can probably just write this part in C
  • Or just start building my own lightweight wrapper with direct usage of bindgen

Vlcn bindings

  • Matt released a very clean set of SQLite bindings
  • Seems to expose most (all?) of the SQLite API
  • nostd compatible
  • currently seems to require rust nightly?

VFS stacking

  • SQLite has the concept of VFS stacking (or shimming)
  • At any point SQLite has a "default" vfs
  • You can call sqlite3_vfs_find(0) to get the current default VFS
  • Then, if you want to write a "higher order vfs" the recommended approach is to wrap and then replace the current default VFS
  • Good example of this is the checksum extension

SQLite batch write mode (atomic write mode)

  • SQLite VFS's can implement a IOCAP + FCNTL which signals support for batch atomic writes
  • need to set the SQLITE_IOCAP_BATCH_ATOMIC bit
  • During a batch write SQLite will make no other calls on the same file object except for calls to xWrite and xFileControl
  • this allows the VFS to internally optimize batch writes to the underlying file, but must guarantee that the writes are committed atomically to durable storage (or rolled back completely) upon receiving the COMMIT or ROLLBACK FCNTL's

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant