mirror of
https://github.com/aljazceru/turso.git
synced 2025-12-27 04:54:21 +01:00
927a1f158a
## Background PR #2065 fixed a bug with table btree seeks concerning boundaries of leaf pages. The issue was that if we were e.g. looking for the first key greater than (GT) 100, we always assumed the key would either be found on the left child page of a given divider (e.g. divider 102) or not at all, which is incorrect. #2065 has more discussion and documentation about this, so read that one for more context. ## This PR We already had similar handling for index btrees as #2065 introduced for table btrees, but it was baked into the `BTreeCursor` struct's seek handling itself, whereas #2065 handled this on the VDBE side. This PR unifies this handling for both table and index btrees by always doing the additional cursor advancement in the VDBE. Unfortunately, unlike table btrees, index btrees may also need to do an additional advance when they are looking for an exact match. This resulted in a bigger refactor than anticipated, since there are quite a few VDBE instructions that may perform a seek, e.g.: `IdxInsert`, `IdxDelete`, `Found`, `NotFound`, `NoConflict`. All of these can potentially end up in a similar situation where the cursor needs one more advance after the initial seek, and they were currently calling `cursor.seek()` directly and expecting the `BTreeCursor` to handle the auto-advance fallback internally. For this reason, I have 1. removed the "TryAdvance"-ish logic from the index btree internals and 2. extracted a common VDBE helper `fn seek_internal()` - heavily based on the existing `op_seek_internal()`, but decoupled from instructions and the program counter - which all the interested VDBE instructions will call to delegate their seek logic. Closes #2083 Reviewed-by: Nikita Sivukhin (@sivukhin) Reviewed-by: Pere Diaz Bou <pere-altea@homail.com> Closes #2084