Due to the left-prefix rule of indexes, for an index key to be usable,
it needs to:
- Use the columns in contiguous order (0, 1, 2...)
* eg if WHERE refers to cols 0 and 2, only 0 can be used
- Stop at the first range operator
* eg if WHERE: col1 = 5 AND col2 > 5 AND col3 = 5, only col1 and col2
can be used.
This wasn't properly tested, and resulted in simulator failures (e.g.
seed `10818913476224476676` which no longer fails with this fix). Added
some regression tests for this behavior, as well.
Reviewed-by: Preston Thorpe (@PThorpe92)
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1698
Due to the left-prefix rule of indexes, for an index key to be usable,
it needs to:
- Use the columns in contiguous order (0, 1, 2...)
* eg if WHERE refers to cols 0 and 2, only 0 can be used
- Stop at the first range operator
* eg if WHERE: col1 = 5 AND col2 > 5 AND col3 = 5, only col1 and col2
can be used.
This wasn't properly tested, and resulted in simulator failures. Added
some regression tests for this behavior.
The major change in this PR is the following:
- It refactors deserializing the record from the cell so that it does
not happen in `next()` or `prev()`, but lazily when it is needed. This
will allow a further enhancement where we only read a _partial_ section
of the record payload, e.g. when `Insn::Column` is requested by the
VDBE, we can only deserialize the relevant column.
It also fixes multiple bugs in `BTreeCursor`
Follow-ups:
ASAP: fix performance regression (probably due to too much record
invalidation)
ASAP: do post-balance seek key calculation only when balance will be
needed
ASAP: fix balancing scenario where interior index cell is deleted - even
if leaf doesnt require balance, parent might. both need to be checked
LATER: implement safe way to use indexes for UPDATE -- ephemeral indexes
needed, see FIXME in `optimizer/mod.rs`
LATER: implement on-demand serialization of parts of the record, instead
of entire record
Closes#1664
This PR is extracted from #1674. This PR creates the optional feature
flag `simulator` that exposes the numeric module and enables an optional
Serde derive on limbo's `Value` type. Additionally, it also namespaces
all of the exec_* functions that operate on a `Value` or indirectly
operate on a `Value` (e.g `exec_like` operates on a pattern string that
is derived from the `Value`). This is necessary so that instead of
reimplementing all of the expected behaviours of different operations
inside the simulator, we can just tap into the existing code we already
have. The next step for this will be wrap be to use `Value` inside the
simulator, which is something that I did in #1674.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1692
My guess as to why the sleep solves the problem is that when you ask
Limbo to quit it needs to checkpoint and with large blobs this probably
takes a while. What I think happens is:
- Now after the python code asks for the program to quit, it already
tries to sleep to allow the checkpointing to succeed
- It terminates the pipe
- Then kills it so that the locking of file is dropped sooner
Then later, we open another shell with SQLite in `test.test_compat()`
and try to run some queries in the database, but the file locking is
still in place. This is my guess on what is going on. I remember
@PThorpe92 had a similar problem a while back on something similar to
this.
```python
def quit(self) -> None:
self._write_to_pipe(".quit")
sleep(0.3)
self.pipe.terminate()
self.pipe.kill()
```
This PR also adds a `PRAGMA integrity_check` for the write tests
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#1694