Few small tweaks in SDKs:
1. Export `ConnectionSync` type from Python SDK
2. Remove dependency on `conn_raw_api` and corresponding methods from
rust bindings - no one use them so let's drop support for this feature
completely
3. Add Waker dependency in the sdk-kit in order to integrate it later to
rust bindings
4. Add io_uring feature to the sdk-kit
Closes#4284
The DX is right now pretty terrible:
```
penberg@vonneumann turso % cargo run -- hello.db
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
Running `target/debug/tursodb hello.db`
Turso v0.4.0-pre.18
Enter ".help" for usage hints.
Did you know that Turso supports live materialized views? Type .manual materialized-views to learn more.
This software is in BETA, use caution with production data and ensure you have backups.
turso> PRAGMA journal_mode = 'experimental_mvcc';
× Invalid argument supplied: MVCC is not enabled. Enable it with `--experimental-mvcc` flag in the CLI or by setting the MVCC option in `DatabaseOpts`
turso>
```
To add insult to the injury, many SDKs don't even have a way to enable
MVCC via database options. Therefore, let's remove the flag altogether.
Instead of manually getting the inner connection everytime with locking
and error handling add a new function and call it.
Also replaces the one instance of an unwrap with an expect as per
project preferences
Refactor to remove unwrap, also added:
- an assertion to catch database failure
- an integer column to make the example a little more informative on how
to use binding
Closes#3748
Right now if any error happens during an interactive tx that causes the
`Transaction` to drop, the program will panic.
To prevent this, we store the `DropBehavior` of the transaction on the
`Connection` when it drops and issue the corresponding action (ROLLBACK
/ COMMIT / IGNORE / PANIC) the next time `Connection` is used to access
the database. This defaults to `IGNORE`.
I don't know how good this solution is, but we can at least prevent a
panic by storing whether the connection has a dangling transaction and
roll it back automatically the next time the connection tries to do
something.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3750
Closes#3748
Right now if any error happens during an interactive tx that causes the
`Transaction` to drop, the program will panic.
I don't know how good this solution is, but we can at least prevent a panic
by storing whether the connection has a dangling transaction and roll it back
automatically the next time the connection tries to do something.
essentially after the first runthrough of `op_transaction` per a given
`ProgramState`, we weren't resetting the instruction state to `Start´ at
all, which means we didn't do any transaction state checking/updating
after that.
PR includes a rust bindings regression test that used to panic before
this change, and I bet it also fixes this issue in turso-go:
https://github.com/tursodatabase/turso-go/issues/28Closes#3516
essentially after the first runthrough of `op_transaction` per a
given `ProgramState`, we weren't resetting the instruction state
to `Start´ at all, which means we didn't do any transaction state
checking/updating.
PR includes a rust bindings regression test that used to panic before
this change, and I bet it also fixes this issue in turso-go:
https://github.com/tursodatabase/turso-go/issues/28
Now returns e.g.:
```rust
SqlExecutionFailure(
"Invalid argument supplied: Unknown parameter ':email' for query 'INSERT INTO users (email, created_at) VALUES (?, ?)'.
Make sure you're using the correct parameter syntax - named: (:foo), positional: (?, ?)"
)
```
instead of unwrapping a None value and panicing
