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.
1. current implementation did not use the custom PartialOrd
implementation for RefValue
2. current implementation did not take collation into account
I don't have a test for this in this PR but it fixes an issue related to
#1757
EDIT:
Okay, it appears the first commit cannot be merged by itself because
since it fixes the incorrect comparison logic, now our UNION tests fail
due to UNIQUE constraint violation (since we are now correctly detecting
duplicates). I have introduced a workaround for this in https://github.c
om/tursodatabase/turso/pull/2001/commits/cb8a576501702cf91713c7f76520501
77318c49c
So, in effect, this PR:
Closes#1757
But, I will make better fixes in #1988 later.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2001
