* 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
Follow-up to #3847.
Adds support for subqueries in all other positions of a SELECT (the
result list, GROUP BY, ORDER BY, HAVING, LIMIT, OFFSET).
Turns out I am a sql noob and didn't realize that correlated subqueries
are supported in basically all positions except LIMIT/OFFSET, so added
support for those too + accompanying TCL tests.
Thankfully the abstractions introduced in #3847 carry over to this very
well so the code change is relatively small (over half of the diff is
tests and a lot of the remaining diff is just moving logic around).
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3852
Closes#3853
Currently LIMIT 0 jumps to "after the main loop", and it is done before
ORDER BY and GROUP BY cursor have had a chance to be initialized, which
causes a panic.
Simplest fix for now is to delay the LIMIT initialization.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3854
I discovered a flaw in our current translation that makes queries of type
HAVING foo IN (SELECT ...) not work properly - in these cases we need to
defer translation of the subquery until later.
I will fix this in a future PR because I suspect it's not trivial.
This PR completely integrate custom indices to the query planner.
In order to do that new `Cursor::IndexMethod` is introduced with few
correlated changes in the VM implementation:
1. Added special `IndexMethod{Create,Destroy,Query}` opcodes to handle
index method creation, deletion and query
2. `Next` , `IdxRowid` , `IdxInsert`, `IdxDelete` opcodes updated to
properly handle new cursor case
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3827
