This PR introduces test for SQLite3 API implementation, adding both unit
tests in Rust and maintaining existing C compatibility tests.
## Changes
- Added unit tests for core SQLite3 operations in `lib.rs`:
- Database initialization and shutdown
- Memory database operations
- Error code handling and messages
- Statement preparation and execution
- Version information verification
Closes#1108
This PR adds support for `DROP TABLE` and addresses issue
https://github.com/tursodatabase/limbo/issues/894
It depends on https://github.com/tursodatabase/limbo/pull/785 being
merged in because it requires the implementation of `free_page`.
EDIT: The PR above has been merged.
It adds the following:
* an implementation for the `DropTable` AST instruction via a method
called `translate_drop_table`
* a couple of new instructions - `Destroy` and `DropTable`. The former
is to modify physical b-tree pages and the latter is to modify in-memory
structures like the schema hash table.
* `btree_destroy` on `BTreeCursor` to walk the tree of pages for this
table and place it in free list.
* state machine traversal for both `btree_destroy` and
`clear_overflow_pages` to ensure performant, correct code.
* unit & tcl tests
* modifies the `Null` instruction to follow SQLite semantics and accept
a second register. It will set all registers in this range to null. This
is required for `DROP TABLE`.
The screenshots below have a comparison of the bytecodes generated via
SQLite & Limbo.
Limbo has the same instruction set except for the subroutines which
involve opening an ephemeral table, copying over the triggers from the
`sqlite_schema` table and then re-inserting them back into the
`sqlite_schema` table.
This is because `OpenEphemeral` is still a WIP and is being tracked at
https://github.com/tursodatabase/limbo/pull/768
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#897
This pull request integrates MVCC with the VDBE.
The long term plan is to implement SQLite `BEGIN CONCURRENT` by
introducing a "MV store" abstraction (that implements the Hekaton in-
memory MVCC index) above the pager. Traditional SQLite transactions use
the pager and the WAL, but MV store has its own transaction path that
updates the in-memory multi-versioned index. If a key does not exist in
the MVCC index, we read records from the pager. When a MVCC transaction
commits, we emit WAL entries.
In this pull request, we wire up the MVCC transaction machinery to VDBE
and multi-version cursor to the b-tree cursor. Currently, the database
either runs in normal b-tree mode or in in-memory MVCC, but we need to
explore if we can make it a hybrid solution where you can read from both
MVCC index and B-Tree. Note that this pull request also does not add
logical logging to a file, which is something we'll defer for later.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#917
While adding logs to our locks in `Wal` I noticed we weren't cleaning up
connection's transaction state. This PR set to `TransactionState::None`
once commited and calls `end_read_txn` and `end_tx` in case of write.
Fixes#1004
Reviewed-by: Pekka Enberg <penberg@iki.fi>
Closes#1099
The logging code that writes out transactions to disk needs to write out
the byte array that we actually use. The code is less hairly without the
generics so drop them.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1100
The logging code that writes out transactions to disk needs to write out
the byte array that we actually use. The code is less hairly without the
generics so drop them.
I don't know when and why we dropped log::* in favor of tracing but when
it was done, it made relevant logs not appear any more while debugging
so... I added test_log::test which helps by automatically adding info
logs from trace package (useful for printing seeds too).
Closes#1097
I don't know when and why we dropped log::* in favor of tracing but when it was done, it made relevant logs not appear any more while debugging so... I added test_log::test which helps by automatically adding info logs from trace package.
This is an umbrella PR for multi threading where I modify the following:
* Loaded extensions (`syms`) are now moved to `Connection` as loading
extensions in SQLite is per connection and not per database.
* `Schema` is not a `RWLock` so that it behaves equally to SQLite where
schema changes block preparing new statements.
* Sprinkled a bunch of `unsafe impl Send` and `unsafe impl Sync` on top
of all `IO` implementations and inner structures for now in order to
allow multi threading. Ideally this will be enforced with transaction
locks and internal locks instead of throwing a bunch of mutexes like
rust would like us to do -- this means the work is not finished and
rather started for future improvements.
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#1091
This makes it work like in SQLite where only one schema writer is permitted and readers will return error while preparing statement if the schema is changing.
