This makes `nix build .#turso_cli` succeed.
#835 argueed to remove nix packaging from the repo. I agree and hope
that a talented maintainer will include `turso_cli` in nixpkgs.
Given the currently broken state and the recent Beta release, maybe it's
worth to unbreak it for some last time.
Closes#3879
* Fixes bug #3674
* With this fix:
```
turso> WITH t AS (SELECT 1), t AS (SELECT 2) SELECT * FROM x;
× Parse error: duplicate WITH table name: t
```
Reviewed-by: Preston Thorpe <preston@turso.tech>
Reviewed-by: Mikaël Francoeur (@LeMikaelF)
Closes#3719
## Purpose
* Implement `setObject(int, Object)` to support binding of common Java
types to SQL parameters in JDBC4.
* This implementation currently covers only standard JDBC4 supported
types. LOB and stream bindings are not yet implemented.
## Changes
* Implemented JDBC4PreparedStatement#setObject(int, Object) handling for
* `String`, `Integer`, `Long`, `Boolean`, `Double`, `Float`, `Byte`,
`Short`
* `byte[]`, `Date`, `Time`, `Timestamp`, `BigDecimal`
* Added validation for unsupported types (`Blob`, `Clob`, `InputStream`,
`Reader`)
* Added corresponding unit test `testSetObjectCoversAllSupportedTypes`
to verify correctness
## Note
* Additional work (e.g., LOB/Stream handling) will be addressed
separately once driver support is available.
## Related Issue
#615
Reviewed-by: Kim Seon Woo (@seonWKim)
Closes#3864
The Antithesis config image was not being uploaded during CI runs, only
the workload image. This caused experiment failures when the config
image expired from the registry after 6 months of inactivity.
Closes#3863
The Antithesis config image was not being uploaded during CI runs, only
the workload image. This caused experiment failures when the config
image expired from the registry after 6 months of inactivity.
This PR fixes sync engine bug which leads to the state of db going back
in time.
The mistake was made in the pull operation which before fetched
information about last commited changes to the remote separately. This
crates a problem since pull already works with fixed WAL updates
received earlier from remote - and this WAL update can be inconsistent
with more fresh value of last_change_id fetched from remote.
The fix is to use only WAL update and "extract" necessary information
from it. In order to do that sync now read meta sync table while pull
operation is in progress (at the moment when local changes are rolled
back and remote changes already applied) and do not use any external
source to consume that information.
Also, this PR fixes bug in the JS tursodatabase client and reset
statement in the finally block opposed to the previous approach to reset
statement at the beginning. The problem with previous approach were in
cases when client do not fully consumed the statement (e.g. abort
iteration and take only one row) in which case the statement will be
kept active and can prevent another write transaction from starting or
just occupy place as a read transaction.
Closes#3860
- before we fetched pull generation and last_change_id from the remote during pull - which is incorrect because fetched information can be inconsistent with WAL updates we received from the server (latest server state can be in "future" compared to the WAL updates we got since we can make push in parallel with updates pull operation)
- now we read information about "server state" (pull generation, last_change_id) directly from the local DB right after we applied changes from the remote which get us consistent view on the state considering WAL updates we got
- also fetching remote in the pull is bad - since pull block writes and network call with unpredictable latency poorly affect writes to the database
This PR reset cursor state in the `stmt.reset()` method because under
the hood statement caches some BTree state which can be no longer valid
at the moment of next statement run.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3859
Reset cached value for `move_to_right_state` in case of `balance_quick`.
I don't know if it's possible to hit this situation with current
generation of VM programs - so don't know what test I can add here.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3858
thread 'query_processing::test_read_path::test_stmt_reset' panicked at core/storage/sqlite3_ondisk.rs:754:9:
assertion failed: self.page_type() == PageType::TableLeaf
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test query_processing::test_read_path::test_stmt_reset ... FAILED