Now, you can upload driver zar to Datagrip and use Turso database.
<img width="852" alt="image" src="https://github.com/user-
attachments/assets/27b071c3-bef7-4c4a-926d-9225de3c5a5b" />
## How to set up
### Build jar file
command: `make libs && make publish_local`
- this will build and put your jar file under `~/.m2/...`
### Register driver
### Set up datasource
Closes#1971
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
Makes it easier to test the feature:
```
$ cargo run -- --experimental-indexes
Limbo v0.0.22
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database
limbo> CREATE TABLE t(x);
limbo> CREATE INDEX t_idx ON t(x);
limbo> DROP INDEX t_idx;
```
- `Update` query doesn't update `n_changes`. Let's make it work
- Add `InsertFlags` to add meta information related to insert operations
- For update query, add `UPDATE` flag
- Currently, the update query executes `Insn::Delete` and `Insn::Insert`
internally, it increases `n_change` by 2. So, for the update query,
let's skip increasing `n_change` for the `Insn::Insert`
https://github.com/tursodatabase/limbo/issues/1681
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1683
## Purpose
Implement `getTables` which is used to extract metadata about the
database
## Changes
- Implement `JDBC4DatabaseMetaData's` `getTables` method
- Extract `JDBC4ResultSet` as field in `JDBC4PreparedStatement`
## Related Issue
https://github.com/tursodatabase/limbo/issues/615Closes#1687
OwnedValue has become a powerhouse of madness, mainly because I decided
to do it like that when I first introduced AggContext. I decided it was
enough and I introduced a `Register` struct that contains `OwnedValue`,
`Record` and `Aggregation`, this way we don't use `OwnedValue` for
everything make everyone's life harder.
This is the next step towards making ImmutableRecords the default
because I want to remove unnecessary allocations. Right now we clone
OwnedValues when we generate a record more than needed.
We currently have two value types, `Value` and `OwnedValue`. The
original thinking was that `Value` is external type and `OwnedValue` is
internal type. However, this just results in unnecessary transformation
between the types as data crosses the Limbo library boundary.
Let's just follow SQLite here and consolidate on a single value type
(where `sqlite3_value` is just an alias for the internal `Mem` type).
The way this will eventually work is that we can have bunch of
pre-allocated `OwnedValue` objects in `ProgramState` and basically
return a reference to them all the way to the application itself, which
extracts the actual value.
