When an `UPDATE` statement modifies a table's `INTEGER PRIMARY KEY` (which acts as a `rowid` alias) alongside other indexed columns, the index entries were incorrectly retaining the old `rowid`. This led to stale index references, causing subsequent queries to return incorrect results.
This change ensures that when the `rowid` alias is part of the `SET` clause in an `UPDATE` statement, the new `rowid` value is used for generating and updating index records. This guarantees that all index entries correctly point to the updated row, resolving the data inconsistency.
This PR aims to add some more comments and documentation to the Rust
binding. It also fixes an issue where you could not reuse the statement
after it ran to completion or errored. Now the statement resets in those
cases. Also implemented `Stream` for the Rows struct allowing users to
leverage the built-in iterator like methods for better ergonomics.
Closes#1905
This PR adds tests for the
[`expand()`](https://github.com/WiseLibs/better-
sqlite3/blob/master/docs/api.md#expandtogglestate---this) method of the
better-sqlite3 API.
It can't be implemented in limbo right now, because the table names
aren't surfaced in the `Statement` object (in core).
Closes#1907
This PR introduces the `FsyncNoWait` property and `FaultyQuery`
property.
`FsyncNoWait` does the following:
- Executes a query
- Does not wait for fsync
- Reopens and closes the connections and database
- executes the query again waiting for all io
- asserts that both queries went through and that all values in table
are as expected
`FaultyQuery` does the following:
- Tries to execute a query
- Asks IO to inject a fault eventually
- asserts that all values in table are as expected
With these changes, I am detecting problems in both Properties. In
`FsyncNoWait`, I am getting assertion errors,
but in `FaultyQuery` I am consistently hitting hangs.
Closes#1871
