overwrite_cell() requires that the cursor state is pointing to a valid
record, but this was not currently set properly.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1598
With Blacksmith runners, it errors out as follows:
```
npm notice Publishing to https://registry.npmjs.org/ with tag next and public access
npm notice publish Signed provenance statement with source and build information from GitHub Actions
npm notice publish Provenance statement published to transparency log: https://search.sigstore.dev/?logIndex=221582002
npm error code E422
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/@tursodatabase%2flimbo - Error verifying sigstore provenance bundle: Unsupported GitHub Actions runner environment: "self-hosted". Only "github-hosted" runners are supported when publishing with provenance.
npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2025-05-28T08_42_29_830Z-debug-0.log
Error: Process completed with exit code 1.
```
Currently in the main translation logic after planning and optimization,
we don't _really_ need to pass a `&mut Vec<WhereTerm>` around anymore,
except for the fact that virtual table constraint resolution is done ad-
hoc in `init_loop()`.
Even there, the only thing we mutate is `WhereTerm::consumed` which is a
boolean indicating that the term has been "used up" by the optimizer and
shouldn't be evaluated as a normal where clause condition anymore.
In the upcoming branch for WHERE clause subqueries, I want to store
immutable references to WHERE clause expressions in `Resolver`, but this
is unfortunately not possible if we still use the aforementioned mutable
references.
Hence, we can temporarily make `WhereTerm::consumed` a `Cell<bool>`
which allows us to pass an immutable reference to `init_loop()`, and the
`Cell` can be removed once the virtual table constraint resolution is
moved to an earlier part of the query processing pipeline.
Closes#1597
Currently in the main translation logic after planning and optimization,
we don't _really_ need to pass a &mut Vec<WhereTerm> around anymore, except
for the fact that virtual table constraint resolution is done ad-hoc in
`init_loop()`. Even there, the only thing we mutate is `WhereTerm::consumed`
which is a boolean indicating that the term has been "used up" by the optimizer
and shouldn't be evaluated as a normal where clause condition anymore.
In the upcoming branch for WHERE clause subqueries, I want to store immutable
references to WHERE clause expressions in `Resolver`, but this is unfortunately
not possible if we still use the aforementioned mutable references.
Hence, we can temporarily make `WhereTerm::consumed` a `Cell<bool>` which allows
us to pass an immutable reference to `init_loop()`, and the `Cell` can be removed
once the virtual table constraint resolution is moved to an earlier part of the
query processing pipeline.
Currently we have some usages of LIMIT where the actual limit counter is
initialized next to the DecrJumpZero instruction, and then
`program.mark_last_insn_constant()` is used to hoist the counter
initialization to the beginning of the program.
This is very fragile, and already FROM clause subquery handling works
around this with a hack (removed in this PR), and (upcoming) WHERE
clause subqueries would also run into problems because of this, because
the LIMIT might need to be initialized once for every iteration of the
subquery.
This PR removes those usages for LIMIT, and LIMIT processing is now more
intuitive:
- limit counter is now initialized at the start of the query processing
- a function init_limit() is extracted to do this for
select/update/delete
Closes#1591
Currently we have some usages of LIMIT where the actual limit counter
is initialized next to the DecrJumpZero instruction, and then
`program.mark_last_insn_constant()` is used to hoist the counter
initialization to the beginning of the program.
This is very fragile, and already FROM clause subquery handling works
around this with a hack (removed in this PR), and (upcoming) WHERE clause
subqueries would also run into problems because of this, because the LIMIT
might need to be initialized once for every iteration of the subquery.
This PR removes those usages for LIMIT, and LIMIT processing is now more
intuitive:
- limit counter is now initialized at the start of the query processing
- a function init_limit() is extracted to do this for select/update/delete
1. allow calling op_null with Insn::BeginSubrtn
- BeginSubrtn is identical to Null, but named differently so that
its use in context is clearer
2. Insn::Return: add possibility to fallthrough on non-integer values as
per sqlite spec
Closes#1588
This pull request implements the `libsql_wal_get_frame()` API. To do
that, we also introduce a `wait_for_completion()` API in I/O dispatcher.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1533
Found this when reviewing #1528 locally and this was crashing
```sql
INSERT INTO t SELECT * FROM generate_series(1,10,1);
```
Reason was that `op_vopen` was not replacing the already allocated
cursor slot, but using `.insert()`
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1583
If we don't reset the state of `IdxDelete`, next `IdxDelete` will start
in `Deleting` state which is completely wrong since it should seek from
the start.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1584
Closes#1528 .
- Modified `translate_select` so that the caller can define if the
statement is top-level statement or a subquery.
- Refactored `translate_insert` to offload the translation of multi-row
VALUES and SELECT statements to `translate_select`
- I did not try to change much of `populate_column_registers` as I did
not want to break `translate_virtual_table_insert`. Ideally, I would
want to unite this remaining logic folding `populate_column_registers`
into `populate_columns_multiple_rows` and the
`translate_virtual_table_insert` into `translate_insert`. But, I think
this may be best suited for a separate PR.
## TODO
- ~Tests~ - *Done*
- ~Need to emit a temp table when we are selecting and inserting into
the Same Table -
https://github.com/sqlite/sqlite/blob/master/src/insert.c#L1369~ -
*Done*
- Optimization when table have the exact same schema - open an Issue
about it
- Virtual Tables do not benefit yet from this feature - open an Issue
about it
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1566
Before #1570 , we never read anything from the on-disk WAL at startup,
so the `test_wal_frame_count()` test assertion `frame_count == 0`would
always pass, regardless of whether there was anything in the WAL or not
Now that the actual bug is fixed, the current test isn't idempotent
because the `clone_test_db.sh` command does not clear the wal, just the
db file
Closes#1581
- Instead of using a confusing `CheckpointStatus` for many different
things, introduce the following statuses:
* `PagerCacheflushStatus` - cacheflush can result in either:
- the WAL being written to disk and fsynced
- but also a checkpoint to the main DB file, and fsyncing the
main DB file
Reflect this in the type.
* `WalFsyncStatus`
- previously `CheckpointStatus` was also used for this, even
though fsyncing the WAL doesn't checkpoint.
* `CheckpointStatus`/`CheckpointResult` is now used only for actual
checkpointing.
- Rename `HaltState` to `CommitState` (program.halt_state ->
program.commit_state)
* `HaltState`'s only variant was `HaltState::Checkpointing` but it
wasn't necessarily reflective of checkpoint being in progress.
* Now the variants are `CommitState::Ready` and
`CommitState::Committing` and `commit_state` is
non-optional in `ProgramState`
- Make `wal` a non-optional property in `Pager`
* This gets rid of a lot of `if let Some(...)` boilerplate
* For ephemeral indexes, provide a `DummyWAL` implementation that does
nothing.
- Rename `program.halt()` to `program.commit_txn()`
- Add some documentation comments to structs and functions
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#1578
This PR:
- Fix compatibility for variadic functions;
- Adds pragma, transaction, close, and pluck methods;
- Add variables to get, iterate, and all methods
Closes#1576
To whomever may be reviewing this PR,
**[Blacksmith](https://www.blacksmith.sh/) is the fastest way to run
your GitHub Actions.**
## What does this PR change?
This PR has been automatically generated by a team member in your GitHub
organization using Blacksmith's [Migration
Wizard](https://docs.blacksmith.sh/introduction/quickstart), or MigWiz
for short. This PR changes the following:
1. Updates your selected workflows to use Blacksmith's `runs-on:
blacksmith-4vcpu-ubuntu-2204`. Learn more about the [different instances
available to choose from](https://docs.blacksmith.sh/blacksmith-
runners/config).
2. Updates your `actions/cache`, `actions/setup-*` to use Blacksmith's
`useblacksmith/cache`, `useblacksmith/setup-*`. Learn more about
[Blacksmith's cache action](https://docs.blacksmith.sh/blacksmith-
caching/dependencies-actions).
## FAQ
- Is this free? The first 3,000 minutes per month are free.
- Who uses Blacksmith? Clerk, Ashby, VEED, and 300+ others.
- What's the catch? There is none. Merge this thing already.
Closes#1579
