- Define a common trait `AeadCipher` for encryption/decryption.
- Provide methods for both "combined" and "detached" encryption modes:
- encrypt / decrypt
- encrypt_detached / decrypt_detached
Fixes https://github.com/tursodatabase/turso/issues/2704
The PR decrypts the page referred to by the WAL frame while reading raw
frames.
<img width="923" height="189" alt="Screenshot 2025-08-31 at 12 42 53 AM"
src="https://github.com/user-
attachments/assets/5e353cf3-aae7-4260-9378-ee2a2cde3f69" />
Reviewed-by: Avinash Sajjanshetty (@avinassh)
Closes#2762
## Changes
- Refactor sql generation to always accept a `Context` trait object so
we can query the current Generation `Opts`. This change allows us to be
more granular in generating our sql statements. It also opens
opportunities for us to add even more knobs to tweak generation as
needed. I tried to make this as generic as possible as I believe this
library can be useful for fuzz testing outside the simulator.
- Introduce `Profile` struct that aggregates the different
configurations needed to execute the simulator. With this Profile struct
we can bias sql generation towards different statements and create
predefined profiles.
`WriteHeavy` Profile:
```rust
Profile {
query: QueryProfile {
gen_opts: Opts {
// TODO: in the future tweak blob size for bigger inserts
// TODO: increase number of rows as well
table: TableOpts {
large_table: LargeTableOpts {
large_table_prob: 0.4,
..Default::default()
},
..Default::default()
},
query: QueryOpts {
insert: InsertOpts {
min_rows: NonZeroU32::new(5).unwrap(),
max_rows: NonZeroU32::new(11).unwrap(),
},
..Default::default()
},
..Default::default()
},
select_weight: 30,
insert_weight: 70,
delete_weight: 0,
update_weight: 0,
..Default::default()
},
..Default::default()
};
```
As you can see we disable the `delete` and `update` weights, decrease
`select` and increase `insert` weights. This means that we disable
updates and deletes in favor of inserting more data and checking the
validity of the database with fewer select statements.
- `Profile` and `Opts` are validated with `garde` and can generate json
schemas with `schemars` so that we can have editor integration when
creating new profiles to play with.
- Added some docs in the README explaining how you can add LSP
integration for the Json config by generating a `JsonSchema` file
Closes#2852
Instead of using static elements, use a dynamically generated DBSP-
circuit to keep views.
The DBSP circuit is generated from the logical plan, which only supports
enough for us to generate the DBSP circuit at the moment.
The state of the view is still kept inside the IncrementalView, instead
of materialized at the operator level. As a consequence, this still
depends on us always populating the view at startup. Fixing this is the
next step.
Closes#2815
This is implementation of #2801, basically repeating of `sqlite` output.
1. I do not want any bike-shedding, so I am totally fine with sqlite
version. For me it was mainly fun trying to work with Rust. On the other
hand, if it will be needed to do it somehow differently, than I am
totally fine with that. Even more fun :-)
2. I do not know where tests for this kind of things are, sorry. If
tests are needed and somebody can point to me to the place where they
can be found, I'll be more than happy to add them as well.
Currently, I can only show how it looks like this way:
```bash
> target/debug/tursodb -m records ../db1
Turso v0.1.4
Enter ".help" for usage hints.
This software is ALPHA, only use for development, testing, and experimentation.
turso> CREATE TABLE test(x INT, some_text TEXT, val DOUBLE);
turso> INSERT INTO test VALUES (100, "very important info", 23.12), (2, NULL, 3.14159265), (98, "yet another very important and long text record", NULL);
turso> SELECT * FROM test;
x = 100
some_text = very important info
val = 23.12
x = 2
some_text =
val = 3.14159265
x = 98
some_text = yet another very important and long text record
val =
```
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2835
```
Benchmarking Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...: Collecting 100 samples in estimated 5.008
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
time: [4.0081 µs 4.0223 µs 4.0364 µs]
change: [-2.9298% -2.2538% -1.6786%] (p = 0.00 < 0.05)
Performance has improved.
```
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2847
Instead of making a new test that would be the same, just updated this one to show that sqlite and turso (with this pr) match and isnt case sensitive in strict tables.
