Intel MAC builds were removed in https://github.com/tursodatabase/turso/
commit/3547bd10931e030a372bedb4968404301c2936c6 but arm builds were
broken after that.
This PR returns back proper ARM builds for Apple
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3054
This tries to establish smooth as possible experience for browser
packages in web.
In order to do that this PR do the following tricks:
1. export `./vite` entry-point which should be used like `import {
connect } from "@tursodatabase/database-browser/vite"` for Vite bundler
* This entrypoint has fix for the issue
https://github.com/vitejs/vite/issues/8427 which breaks package in the
dev-server mode
* In order to overcome this we do 2 tricks:
- Inline WASM module in order to avoid loading it from the separate
file
- Use same file as entry-point for main thread and for the web
worker
* Note, that we do these tricks only for `development` build and
produce build will be chunked and optimized as usual with Vite and will
treat worker and WASM modules as separate fiels
3. export `./turbopack` entry-point which should be used like `import {
connect } from @tursodatabase/database-browser/turbopack"` for Turbopack
(Next.js) bundler
* This entrypoint has fix for the issue
https://github.com/vercel/next.js/issues/82520'
* In order to overcome this for now we always inline WASM for Next.js
4. Bundle browser libraries in order to easily consume them without need
for bundlers:
* e.g. `import { connect } from
"https://unpkg.com/@tursodatabase/database-browser/bundle/main.es.js";`
5. We vendor `@napi-rs/wasm-runtime` for now in order to fix runtime
errors due to accesses to `process.env.NODE_DEBUG_NATIVE` env var (not
defined in web)
* This should be very temporary solution because I already fixed
wasm-util dependency which cause this error
(https://github.com/toyobayashi/wasm-util/issues/4) and hope that napi-
rs PR will be merged soon: https://github.com/napi-rs/napi-rs/pull/2921
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3017
Particularly we were tracing `ImmutableRecord` / `BTreeKey` which would
then trace the bytes of records. These are super super hot paths and I
think we can probably remove even more to under debug assertions so we
dont eat those atomics/branches all the time.
This PR also introduces the `tracing_release` feature, which turns all
`trace!` and `debug!` macro invocations to noops at compile time, and
makes that feature available for all bindings.
it also removes the unused `lru` dependency, and cleans up the makefile
a bit
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2995
The `run_once()` name is just a historical accident. Furthermore, it now
started to appear elsewhere as well, so let's just call it IO::step() as we
should have from the beginning.
This PR introduces separate `package.browser.json` file for `*-browser`
npm packages (`@tursodatabase/sync-browser` and
`@tursodatabase/database-browser`).
The packages are nearly identical and the only change is `package.json`
content (browser package mentions only WASM optional dependency which
shouldn't confuse NPM and force it to download WASM dep package instead
of native one).
Due to that, innocent "hack" is implemented which swap `package.json`
with `package.browser.json` before publish of `browser` package.
Closes#2906
Using `usize` to compute file offsets caps us at ~16GB on 32-bit
systems. For example, with 4 KiB pages we can only address up to 1048576
pages; attempting the next page overflows a 32-bit usize and can wrap
the write offset, corrupting data. Switching our I/O APIs and offset
math to u64 avoids this overflow on 32-bit targets
Closes#2791
Previously, the encryption module had hardcoded a lot of things. This
refactor makes it slightly nice and makes it configurable.
Right now cipher algorithm is assumed and hardcoded, I will make that
configurable in the upcoming PR
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2722
This patch adds support for per page encryption. The code is of alpha
quality, was to test my hypothesis. All the encryption code is gated
behind a `encryption` flag. To play with it, you can do:
```sh
cargo run --features encryption -- database.db
turso> PRAGMA key='turso_test_encryption_key_123456';
turso> CREATE TABLE t(v);
```
Right now, most stuff is hard coded. We use AES GCM 256. This
information is not stored anywhere, but in future versions we will start
saving this info in the file. When writing to disk, we will generate a
cryptographically secure random salt, use that to encrypt the page. Then
we will store the authentication tag and the salt in the page itself. To
accommodate this encryption hardcodes reserved space of 28 bytes.
Once the key is set in the connection, we propagate that information to
pager and the WAL, to encrypt / decrypt when reading from disk.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2567
