Hi
I noticed you have some partner logos in the README nowadays, and felt
left out... But then I realized this is open source and I can just send
a PR. I assume the order is chronological so as Nyrkiö is the oldest of
these three I put it on top. The order could also be reverse
alphabetical.
Closes#2027
We need to return the original function name, not normalized one to be
compatible with SQLite.
Spotted by SQLite TCL tests.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2017
We need to start transaction implicitly in execute() for DML statements
to make sure first transaction is actually started.
Fixes#2002
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2013
when updating last_insert_rowid we call `return_if_io!(cursor.rowid())`
which yields IO on large records. this causes `op_insert` to insert and
overwrite the same row many times. we need a state machine to ensure
that the insertion only happens once and the reading of `rowid` can
independently yield IO without causing a re-insert.
to reproduce this bad behavior:
```sql
create table t(x);
insert into t values (randomblob(1024*1024));
```
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2000
when updating last_insert_rowid we call return_if_io!(cursor.rowid())
which yields IO on large records. this causes op_insert to insert and
overwrite the same row many times. we need a state machine to ensure
that the insertion only happens once and the reading of rowid can
independently yield IO without causing a re-insert.
Separates cursor.key_exists_in_index() into a state machine. The problem
with the main branch implementation is this:
`return_if_io!(seek)`
`return_if_io!(cursor.record())`
The latter may yield on IO and cause the seek to start over, causing an
infinite loop. With an explicit state machine we can control and prevent
this.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2011
This PR brings the error handling of the js bindings one step closer to
better-sqlite3. There is still some work left for the error handling to
be 100% compatible.
This is my first non-trivial Rust PR, so if you have any comments that
can help me improve, please leave them on the PR.
-----
as part of https://github.com/tursodatabase/turso/issues/1900
Reviewed-by: Diego Reis (@el-yawd)
Closes#2009
Separates cursor.key_exists_in_index() into a state machine. The problem with
the main branch implementation is this:
`return_if_io!(seek)`
`return_if_io!(cursor.record())`
The latter may yield on IO and cause the seek to start over, causing an infinite
loop. With an explicit state machine we can control and prevent this.
Due to how `execute` is implemented, it returns a `Connection` clone
which internally shares a turso_core::Connection with every other
Connection. Since `execute` returns `Connection` and immediatly it is
dropped, it will close connection, checkpoint and leave database in
weird state.
Let's make sure we don't keep using a connection after it was dropped.
In case of executing a query that was closed we will try to rollback and
return early.
Closes#2006
Let's make sure we don't keep using a connection after it was dropped.
In case of executing a query that was closed we will try to rollback and
return early.
Due to how `execute` is implemented, it returns a `Connection` clone
which internally shares a turso_core::Connection with every other
Connection. Since `execute` returns `Connection` and immediatly it is
dropped, it will close connection, checkpoint and leave database in
weird state.
