Implement very basic views using DBSP
This is just the bare minimum that I needed to convince myself that this
approach will work. The only views that we support are slices of the
main table: no aggregations, no joins, no projections.
* drop view is implemented.
* view population is implemented.
* deletes, inserts and updates are implemented.
much like indexes before, a flag must be passed to enable views.
Closes#2530
Add support for more of the SQLite C API.
Bind functions:
- sqlite3_bind_text (with destructor callback)
- sqlite3_bind_blob
Column functions:
- sqlite3_column_text
- sqlite3_column_blob
- sqlite3_column_bytes
Closes#2528
Currently, we have a borrow problem because parse_schema_rows() already
borrows `schema`, but then `apply_view_deltas` does the same:
```
thread 'main' panicked at core/vdbe/mod.rs:450:49:
already mutably borrowed: BorrowError
stack backtrace:
0: __rustc::rust_begin_unwind
at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:697:5
1: core::panicking::panic_fmt
at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/panicking.rs:75:14
2: core::cell::panic_already_mutably_borrowed
at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/cell.rs:799:5
3: core::cell::RefCell<T>::borrow
at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/cell.rs:987:25
4: turso_core::vdbe::Program::apply_view_deltas
at ./core/vdbe/mod.rs:450:26
5: turso_core::vdbe::Program::commit_txn
at ./core/vdbe/mod.rs:468:9
6: turso_core::vdbe::execute::op_halt
at ./core/vdbe/execute.rs:1954:15
7: turso_core::vdbe::Program::step
at ./core/vdbe/mod.rs:430:19
8: turso_core::Statement::step
at ./core/lib.rs:1914:23
9: turso_core::util::parse_schema_rows
at ./core/util.rs:91:15
10: turso_core::Connection::parse_schema_rows::{{closure}}
at ./core/lib.rs:1518:17
11: turso_core::Connection::with_schema_mut
at ./core/lib.rs:1625:9
12: turso_core::Connection::parse_schema_rows
at ./core/lib.rs:1515:9
```
However, this is a read transaction and views are not even enabled,
let's just make `apply_view_deltas()` return early if there's no
processing needed, to skip the schema borrow altogether.
Currently, the simulator complains of the following error:
```
Error: failed with error: 'attempt to multiply with overflow'
```
However, we don't enable views in the simulator so -- despite being an
issue -- we should never see this. Let's fix `op_delete()` some more not
to not even call rowid() unless view processing is enabled.
When building views (soon), it will be important to know which table is
being deleted. Getting from the cursor id is very cumbersome.
What we are doing here is symmetrical to op_insert, and sqlite also
passes table information in one of the registers (p4)
Closes#2529
Implement very basic views using DBSP
This is just the bare minimum that I needed to convince myself that this
approach will work. The only views that we support are slices of the
main table: no aggregations, no joins, no projections.
* drop view is implemented.
* view population is implemented.
* deletes, inserts and updates are implemented.
much like indexes before, a flag must be passed to enable views.
Closes#2530
This is just the bare minimum that I needed to convince myself that this
approach will work. The only views that we support are slices of the
main table: no aggregations, no joins, no projections.
drop view is implemented.
view population is implemented.
deletes, inserts and updates are implemented.
much like indexes before, a flag must be passed to enable views.
When building views (soon), it will be important to know which table
is being deleted. Getting from the cursor id is very cumbersome.
What we are doing here is symmetrical to op_insert, and sqlite also
passes table information in one of the registers (p4)
When building views (soon), it will be important to know which table
is being deleted. Getting from the cursor id is very cumbersome.
What we are doing here is symmetrical to op_insert, and sqlite also
passes table information in one of the registers (p4)
Hi there,
I wasn't able to run the Turso CLI locally following the manual in the
docs (with both the release version and Homebrew). I found out that the
right command is `tursodb` rather than just turso as specified in the
cli/Cargo.toml.
This MR updates the docs and also mention the instruction to install it
with Homebrew.
Demo:
<img width="629" height="129" alt="image" src="https://github.com/user-
attachments/assets/3c684328-dab6-436a-bae6-4b6199f5b0b5" />
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2514
This PR rewrites the `LimboRwLock`, which previously used 3 separate
`AtomicU32` values to store the lock state, in favor of a single,
packed, cache friendly `AtomicU64`.
The previous impl has some complexity and rather hairy edge cases/issues
because we are not updating the lock state together. This PR also
adjusts it to use `Acquire`/`Release` for `load`/`store` operations, and
tries to improve the API of using the locks.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2518
This PR introduces a BufferPool which allocates all (usually) of the
memory we will need up front as two large arenas (one for WAL frames and
one for DB pages) and hands our pages from those two arena allocations.
(each will be 3 MB by default, because 8MB is typically the RL_MEMLOCK
limit so without `setcap cap_ipc_lock` changed, it will not be able to
properly register the arenas with io_uring).
Any additional memory needed will fall back to the previous style buffer
pool, with a simple thread local cache, which should be slightly faster
for most cases.
Closes#2419
