Primary keys that are marked as unique constraint, do not need to have
separate indexes, one is enough. In the case primary key is integer,
therefore rowid alias, we still need an index to satisfy unique
constraint.
The setup-node fails sporadically with the following error:
```
Error: Could not get yarn cache folder path for /home/runner/work/limbo/limbo/bindings/javascript/docs
```
This seems to be a known issue that's not fixed despite the issue being
closed: https://github.com/actions/setup-node/issues/887
Let's disable yarn caching for setup-node in an attempt to reduce CI
failing randomly.
Closes#1487
The setup-node fails sporadically with the following error:
```
Error: Could not get yarn cache folder path for /home/runner/work/limbo/limbo/bindings/javascript/docs
```
This seems to be a known issue that's not fixed despite the issue being closed: https://github.com/actions/setup-node/issues/887
Let's disable yarn caching for setup-node in an attempt to reduce CI
failing randomly.
(Yes, I changed the name of the repo.)
Also switch back to 'cargo' for the parser, which is the original
upstream code. I created 'criterion' because I didn't realize
cargo bench spitz half of the text to stdout the other half to stderr.
This PR attempts to implement Primary Key and Indexes. It supports
Update for Primary Keys as a RowId Alias, Composite Primary Keys, and
Indexes. I tried to resemble as much as possible how SQLite emits the
Opcodes.
~Additionally, to support this I had to fix a bug in the how we searched
for the next records in the `Next` opcode, by introducing a Set of seen
row id's. The problem was that, you need to delete the previous record
and then insert the new record to update. When we did that in a `Rewind`
loop, the current cell index in the cursor was always pointing to the
incorrect place because we were searching for the next record without
checking if we had seen it before. However, I am not sure how this
affects the Btree.~
EDIT: After seeing how bad my fix was, I tried a different approach that
is more in line with what SQLite does. When performing a `Delete` in the
btree, we can save the current `rowid` (`TableBtree`) or the current
`record` for (`IndexBtree`), and then restore the correct position later
in the `next` function by seeking to the saved context. I'm just not
knowledgeable enough yet to be efficient of when we can avoid saving
the context and doing the seek later.
Closes#1429
