Previously, the test queries added in this commit would fail with:
thread 'main' panicked at core/schema.rs:129:34:
not implemented
stack backtrace:
0: rust_begin_unwind
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/panicking.rs:74:14
2: core::panicking::panic
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/panicking.rs:148:5
3: limbo_core::schema::Table::get_root_page
at ./core/schema.rs:129:34
4: limbo_core::translate::main_loop::init_loop
at ./core/translate/main_loop.rs:260:44
5: limbo_core::translate::emitter::emit_query
at ./core/translate/emitter.rs:568:5
6: limbo_core::translate::emitter::emit_program_for_select
at ./core/translate/emitter.rs:496:5
7: limbo_core::translate::emitter::emit_program
at ./core/translate/emitter.rs:187:31
8: limbo_core::translate::select::translate_select
at ./core/translate/select.rs:82:5
9: limbo_core::translate::translate_inner
at ./core/translate/mod.rs:241:13
10: limbo_core::translate::translate
at ./core/translate/mod.rs:95:17
11: limbo_core::Connection::run_cmd
at ./core/lib.rs:416:31
12: <limbo_core::QueryRunner as core::iter::traits::iterator::Iterator>::next
at ./core/lib.rs:916:22
13: limbo::app::Limbo::run_query
at ./cli/app.rs:442:27
14: limbo::app::Limbo::handle_input_line
at ./cli/app.rs:544:13
15: limbo::main
at ./cli/main.rs:51:31
16: core::ops::function::FnOnce::call_once
I am currently working on upgrading Rust to the latest version
(https://github.com/tursodatabase/limbo/pull/1807). Initially, I wanted
to address all Clippy errors in that PR, but I decided to move them into
a separate one to make it easier to review.
**Note:** In the latest version of Clippy, it is considered an error to
place variables after a comma in string formatting macros (e.g.,
`format!`), rather than inside the `{}` placeholders. That's where most
of the errors are coming from.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1827
Although concurrency doesn't work yet (#2059), we do want to support
concurrency, and one good first step is not to make the simulator hang
forever once any connection gets a `Busy` result from the VDBE
Closes#2060
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2061
- Also added a benchmark for opening databases, the main thing that is
slowing `Database::open_file` is `parse_schema_rows`.
- `to_uppercase` was being called multiple times, leaving a relevant
mark on stack traces due to multiple allocations. `make_ascii_upper`
reuses the memory and is faster due to not handling unicode characters
(still compatible with sqlite).
- Do direct btree calls instead of creating a program for updating
`Schema` with `Schema::make_from_btree`.
- Faster type substr comparison using fixed size `u8` slices.
<img width="952" height="507" alt="image" src="https://github.com/user-
attachments/assets/0d0c52ff-05a1-431e-a93d-e333b53c0bb8" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2042
This inhibits ANSI color codes on non-TTY stdouts. It should fix logs
with mangled color codes such as
https://github.com/tursodatabase/turso/issues/2046.
## Result
On this branch:
<img width="1492" height="421" alt="image" src="https://github.com/user-
attachments/assets/1d281203-bda1-41c6-944e-f10dac16834e" />
If I don't pipe or redirect, on this branch, the color is displayed.
On main:
<img width="1496" height="438" alt="image" src="https://github.com/user-
attachments/assets/3844edac-dead-4655-96fb-df6ab5353021" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2052
Closes#2047
the validation code was assuming that:
- if the parent has overflow cells after inserting a divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit, so
it gets pushed to `parent.overflow_cells()`. Parent usable space does
not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the
inserted cell overflowed, and use that to find the left pointer and
assert accordingly.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2050
the validation code was assuming that:
- if the parent has overflow cells after a inserting divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit,
so it gets pushed to `parent.overflow_cells()`. Parent usable space
does not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the inserted
cell overflowed, and use that to find the left pointer and assert accordingly.
We can use `right_page_id` directly to perform the validation instead of
carrying a raw pointer around which might be invalidated by the time we
do the validation.
Closes#2036Closes#1991
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2038
I noticed on instance of the nyrkio github action was still using the
old name. Updating to nyrkio/change-detection@HEAD. All other entries
are already updaeted,
Closes#2037
We can use `right_page_id` directly to perform the validation instead of
carrying a raw pointer around which might be invalidated by the time we
do the validation.
I noticed on instance of the nyrkio github action was still
using the old name. Updating to nyrkio/change-detection@HEAD.
All other entries are already updaeted,
