The completion callback can be invoked only once via `OnceLock`, let's
not crash if we e.g. call `Completion::abort()` on an already finished
completion.
Closes#2673Closes#2674
The completion callback can be invoked only once via `OnceLock`, let's not
crash if we e.g. call `Completion::abort()` on an already finished completion.
Closes#2673
Completions can now carry errors inside of them. This allows us to wait
for a completion to complete or to error. When it errors we can properly
tell the caller of `wait_for_completion` that we errored. This will also
allow us to abort completions.
Currently, this just creates the scaffold for us to store the error in
the completion. But to correctly achieve this, it will require some
refactor of our IO implementations to store the `run_once` error for a
particular completion inside of it instead of short circuiting. This
would also allow us to check for an error in `program.step` and properly
rollback.
Also, creates default impls for some common IO methods, this is
important specially for `wait_for_completion` as we want to check the
error in the `Completion` before returning `Ok`.
Maybe we could also accept a Result type in the completion callback so
that we can execute some sort of compensating action on error, like
unlocking a page so it can be evicted by the page cache later.
**EDIT:** actually implemented this in this PR. We store a `Result`
object inside `CompletionInner` behind a `OnceLock` for thread-safety.
We also pass a result object to Completion callbacks to execute
compensating actions.
Reviewed-by: Avinash Sajjanshetty (@avinassh)
Closes#2589
This pull request brings the JavaScript APIs to almost feature parity
with libSQL. Some corner cases like error messages still need some more
work.
Closes#2669
Closes#2657Closes#2659Closes#2660Closes#2661
1. In simulator, do not assume every error that happens after fault
injection has the literal error message `"Injected fault"`. If an error
happened, all we need to do is not shadow the query into the in-memory
simulator environment -- in other words, we assume whatever the
statement did failed and was rolled back.
2. Do not begin or end transactions inside a nested statement. Nested
statements generally only occur when `ParseSchema` is invoked, which
runs the equivalent of `SELECT * FROM sqlite_schema`. This does not need
a new transaction nor does it need to end the transaction on error,
since the parent statement will handle it.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2666
Right now it is buried under "console".
We have also not updated the list of commands when we added two more,
and this is done in this PR.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2655
<img width="436" height="480" alt="image" src="https://github.com/user-
attachments/assets/d95572cf-b775-43d9-b3fa-b6b1c9ecc64d" />
(cherry-picked example, yes on io_uring we do well with some write
workloads against sqlite)
adds:
`make bench-sqlite VFS=io_uring SQL="insert into products (name,price)
values (1,2);" N=10000`
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2652
FaultyQuery was disabled. We were not simulating faults.
Reviewed-by: Avinash Sajjanshetty (@avinassh)
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2594
