## 1. select equal number of columns per compound subselect in simulator
#2609 fixed compound selects incorrectly, introducing another bug: now
the sim can SELECT a different number of columns per subselect, which is
illegal. this PR forces the sim to select the same number of cols per
subselect.
Depends on #2614 , otherwise the sim constantly fails whenever it
decides to do a compound select with DISTINCT.
Closes#2611
## 2. introduce TableContext for the simulator to properly generate
predicates for Joins
The simulator has a construct called `JoinTable` which is really a
`JoinContext` that includes all the columns from the so-far joined
tables, so that the next table to be joined can refer to columns from
any of those tables. @pedrocarlo 's commit fixes an issue where
`JoinTable` would incorrectly generate predicates with empty table
names. Related: #2618Closes#2616
Closes#2612
Two commits:
## Simplify ORDER BY sorter column remapping
In case an ORDER BY column exactly matches a result column in the
SELECT,
the insertion of the result column into the ORDER BY sorter can be
skipped
because it's already necessarily inserted as a sorting column.
For this reason we have a mapping to know what index a given result
column
has in the order by sorter.
This commit makes that mapping much simpler.
## Fix DISTINCT with ORDER BY
We had a bug where we were checking for duplicates in the DISTINCT
index based on both the result column count plus any ORDER BY columns
not present in the DISTINCT clause.
This is wrong, so fix it by only using the result columns for the
dedupe check.
Closes#2614
We had a bug where we were checking for duplicates in the DISTINCT
index based on both the result column count plus any ORDER BY columns
not present in the DISTINCT clause.
This is wrong, so fix it by only using the result columns for the
dedupe check.
In case an ORDER BY column exactly matches a result column in the SELECT,
the insertion of the result column into the ORDER BY sorter can be skipped
because it's already necessarily inserted as a sorting column.
For this reason we have a mapping to know what index a given result column
has in the order by sorter.
This commit makes that mapping much simpler.
Set in-memory WAL information according to last commited frame
- before that pages_in_frames, frame_cache and last_checksum was set to
the latest written (not commited!) frame in the WAL found on disk
Simple example to reproduce the data-loss:
```sh
n=$RANDOM
./target/debug/tursodb data-loss-$n.db 'create table t(x)';
strace -o /dev/null -e fault=pwrite64:error=EIO:when=5 ./target/debug/tursodb data-loss-$n.db 'insert into t values (randomblob(4 * 4096));'
./target/debug/tursodb data-loss-$n.db 'insert into t values (1);'
./target/debug/tursodb data-loss-$n.db 'select x from t;'
```
The main bug which contributes to the data-loss was update of
`last_checksum` to the value from last frame read from WAL while
actually DB must use checksum of last **commited** frame. Due to this
bug, `insert` from third operation used checksum from last **written**
frame, but continued to append wal from the position after last
**committed** frame. So, fourth operation read WAL, detected checksum
mismatch and dropped all frames written by third operation.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2613
We are relying too much on the currently disabled `FaultyQuery` and
`FsyncNoWait` to assert the basic invariant of "the rows we have
inserted/updated/deleted in the database are still there", so adding
that as a separate `Property` here.
Closes#2610
Problem:
sim was generating compound selects like this:
- pick a random `table`
- create a random single SELECT
- create `n` random compound SELECTs (UNION ALL etc)
assign a WHERE clause that always has a condition based on `table`
This can result in e.g.
```
SELECT a FROM foo WHERE bar.x = 'baz'
```
Solution:
Don't base the WHERE clause on a table that might not be referenced
in the query.
Again, the only reason this wasn't caught before was because `FaultyQuery`
and `FsyncNoWait` are the only paths where this is actually tested with an
assertion, and those are both disabled
Closes#2588
SQLite internally implements `.clone` by doing something like piping
`.dump` into a new connection to a database attached to the file you
want. This PR implements that by adding an `ApplyWriter` that implements
`std::fmt::Write`, and refactors our current `.dump` plumbing to work
with any `Write` interface, so we can `.dump` to stdout or `.dump` to a
new connection, therefore cloning the database.
Reviewed-by: Nikita Sivukhin (@sivukhin)
Closes#2590
Add comprehensive documentation for connecting Turso databases to Claude
Code using the built-in MCP management commands.
This PR addresses the need for easier integration between Turso and
Claude Code by providing clear, step-by-step instructions for users who
want to query their databases using natural language.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2606
Add comprehensive documentation for connecting Turso databases to Claude Code using the built-in MCP management commands.
The new guide includes:
- Quick 3-step setup process
- Visual command breakdown with annotations
- Multiple usage examples (local, absolute paths, project-scoped)
- MCP server management commands
- Example natural language queries users can make
This makes it much easier for developers to integrate their Turso databases with Claude Code without manually configuring JSON files or understanding the underlying MCP protocol details.
bringing #1127 back to life, except better because this doesn't add
Tokio as a dependency for extension lib just for tests.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2418
we spend a shitload of time doing very complex selects in the simulator,
and i'm not sure there has been a lot of gain from them. using up a lot
of the runtime of a simulator run on these can mask other issues.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2605
as @avinassh pointed out, if we have an error in a `writev` call, it
could go unnoticed and the checkpoint could proceed as expected after
not writing the expected total amt.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2601
