Previously all constraints were disabled with an `if false {}` hack.
In this PR:
- enable PRIMARY KEYs and UNIQUE constraints if `experimental_indexes`
compile-time feature is enabled.
- Also enable PRIMARY KEY for exactly INTEGER columns, as INTEGER
PRIMARY KEY does not require an index
- NOT NULL constraint is also now enabled in both cases, as it doesn't
require an index
Closes#1981
We're now mixing different error messages, which makes compatibility
testing pretty hard. Unify on a single, SQLite compatible error message
"no such table".
Closes#1978
We're now mixing different error messages, which makes compatibility
testing pretty hard. Unify on a single, SQLite compatible error message
"no such table".
Previously `ScalarFunc::Glob` only handled Text based values. After this
fix it will be able to handle all types of values.
Now:
```SQL
turso> CREATE TABLE IF NOT EXISTS t0 (c0 REAL );
turso> UPDATE t0 SET c0='C2IS*24', c0=0Xffffffffbfc4330f, c0=0.6463854797956918 WHERE ((((((((t0.c0)AND(t0.c0)))AND(0.23913649834358142)))OR(CASE t0.c0 WHEN t0.c0 THEN 'j2' WHEN t0.c0 THEN t0.c0 WHEN t0.c0 THEN t0.c0 END)))OR(((((((((t0.c0)AND(t0.c0)))AND(t0.c0)))OR(t0.c0)))AND(t0.c0))));
turso> INSERT INTO t0 VALUES (NULL);
INSERT INTO t0 VALUES ('0&');
UPDATE t0 SET c0=2352448 WHERE ((((t0.c0)GLOB(t0.c0))) NOT NULL);
turso> SELECT * from t0;
┌───────────┐
│ c0 │
├───────────┤
│ │
├───────────┤
│ 2352448.0 │
└───────────┘
```
Fixes: https://github.com/tursodatabase/turso/issues/1953Closes#1955
I modified the `better-sqlite3.spec.mjs` test suite to use the dual test
runner from https://github.com/tursodatabase/turso/pull/1941 and I
deleted the `limbo.spec.mjs` test suite, because it's now redundant.
I looked carefully at the diff between the two test suites to make sure
that we didn't lose any coverage with this change.
Closes#1959
In reponse to [discord discussion](https://discord.com/channels/12586588
26257961020/1385754749634084885/1390535068401012858), I thought it would
be better to add a test to show how JDBC4Statement can be used.
Closes#1962
This PR imports the `sync` test suite from libSQL, and modifies the
export structure match `better-sqlite3`, so that at least a few tests
from the new test suite are passing.
I also changed the `package.json` to expose `wrapper.js` as an
entrypoint. I think the plain `index.js` was probably never meant to be
exposed directly to clients, because the wrapper does some important
transformation. It's also how libSQL-js is
[structured](https://github.com/tursodatabase/libsql-
js/blob/main/package.json#L20).
## DualTest test runner
The test suite that I imported was previously run twice, with different
environment variables: one run for libSQL-js, one run for better-
sqlite3. This worked well with libSQL, because it's compatible with
better-sqlite3. But Turso isn't there yet, so even though all tests need
to run on better-sqlite3, not all tests are passing on Turso.
To make it possible to run the test suite on both implementation, and to
make it possible to track the progress of Turso, I've added a `DualTest`
test runner that emulates the API of the Ava test runner, but instead of
a single `test()` function, it exposes two methods: `both()`, and
`onlySqlitePasses()`. The first one runs the test on both
implementations, and the second one also runs it on both, but expects
that Turso will fail.
When Turso is completely compatible with better-sqlite3, it will be easy
to remove the dual-test runner, since it has the same API as Ava.
## Future development
### Existing tests
The existing tests were divided in two files: `better-sqlite3.spec.mjs`,
and `dual-test.mjs` that are kept in sync manually. The first one is
mostly a superset of the second one, with additional tests indicating
behaviour that isn't implemented in Turso yet. I want to merge these
test suites to also use the dual-test test runner. This will make it
easier to evolve test suites and to track the progress of Turso.
### `SqliteError`
Modifying the test called `errors` to `both()` will show that Turso is
still missing an `SqliteError` type, to be compatible with better-
sqlite3. I have the required changes in a stash and will open a PR
shortly.
-----
as part of https://github.com/tursodatabase/turso/issues/1900Closes#1941
Added a threshold to clip input page cache size values to `0`. This
avoid the panic at runtime and also follow's SQLite behavior closely.
Now:
```
Turso v0.1.1
Enter ".help" for usage hints.
This software is ALPHA, only use for development, testing, and experimentation.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database
turso> PRAGMA main.cache_size = 5022422913188235998;
turso> PRAGMA main.cache_size;
┌────────────┐
│ cache_size │
├────────────┤
│ 10 │
└────────────┘
```
Closes: https://github.com/tursodatabase/turso/issues/1952Closes#1954
As adaptive colors use `OSC 11` to query the terminal's background
color, the query string may contaminate test result and cause failures
when running tests in a terminal.
```
make test-vector
SQLITE_EXEC=scripts/limbo-sqlite3 ./testing/vector.test
(testing/testing.db) Running test: vector-functions-valid
Test FAILED: SELECT vector_extract(vector('[]'));
SELECT vector_extract(vector(' [ 1 , 2 , 3 ] '));
SELECT vector_extract(vector('[-1000000000000000000]'));
returned '[]
[1,2,3]
[-1000000000000000000]'
expected '[]
[1,2,3]
[-1000000000000000000]'
^[]11;rgb:158e/193a/1e75^[\make: *** [test-vector] Error 1
```
Closes#1942
Fixes#1890
Once rollback was implement we quickly saw that it lacked support for
schema changes so we had to re-estructure things a bit.
## Example of failure:
```bash
turso> begin;
turso> create table t(x);
turso> rollback;
turso> pragma integrity_check;
thread 'main' panicked at core/storage/sqlite3_ondisk.rs:386:36:
called `Result::unwrap()` on an `Err` value: Corrupt("Invalid page type: 83")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This happened because it thought table `t` existed because we didn't
rollback that schema.
## Changes:
* The most important change: now every connection has a private copy of
schema. On write txn commit we update a global schema shared between
connections in order for new connections to get updated version from
there. In case of rollback, we simply change connection's schema to
previous version. This change allowed us to remove locks for schema
private copy and keeping schema changes locally in case of concurrency.
Sqlite does things differently, they lazily parse schema in case of
outdated schema, this many schema changes to trigger reading schema from
db file which is slow. If we are able to keep local copy in memory, even
when if we add multiprocessing, it will speed up schema reloading by a
bunch.
* `schema_cookie` is now update for every schema change
* `Insn::ParseSchema` had a nasty bug where it would commit all the
changes made in a query that changed a schema, we fixed that by setting
`auto_commit` to `false` before parsing schema, and setting it back to
previous value once schema is parsed.
Closes#1928
