In sqlite3 , we can create primary key with only integer column and
during insert we can pass any value which can be parsed into integer as
shown below. When I tried the same with limbo, it failed. The cause of
this was due to MustBeInt opcode behaviour not aligned with sqlite. This
PR aims to fix it.
Sqlite output
```
SQLite version 3.45.3
sqlite> create table temp (t1 integer, primary key (t1));
sqlite> insert into temp values (1),(2.0),('3'),('4.0');
sqlite> select * from temp;
1
2
3
4
```
Limbo output main branch
```
limbo> create table temp (t1 integer, primary key (t1));
limbo> insert into temp values (1),(2.0),('3'),('4.0');
Parse error: MustBeInt: the value in the register is not an integer
limbo> select * from temp;
1
```
Limbo output with this PR
```
limbo> create table temp (t1 integer, primary key (t1));
limbo> insert into temp values (1),(2.0),('3'),('4.0');
limbo> select * from temp;
1
2
3
4
```
Closes#706
Seed 16184573510628167771 in git hash 7c549bc produces a missing row
error, but the underlying error is `Parse error: table
breathtaking_dimitrakis not found`, which was not obvious without
exposing the error in the message the simulator prints on assertion
failure.
This PR just exposes the inner error, if any.
Closes#704
When we had multiple sql statements in cli/interactive shell, we were
only running one from them as shown below. This PR fixes them.
One added benefit of this is we can add complex sql in the tcl test
files like the changes in insert.test .
sqlite3 output
```
❯ sqlite3 :memory: "select 1;select 2"
1
2
```
Limbo main branch output
```
❯ ./target/debug/limbo.exe :memory: "select 1;select 2;"
1
```
Limbos output with this PR
```
❯ ./target/debug/limbo.exe :memory: "select 1;select 2;"
1
2
```
Reviewed-by: Preston Thorpe <cory.pride83@gmail.com>
Closes#673
I believe this closes#682
```
limbo> CREATE TABLE proficient_barrett (imaginative_etrebilal BLOB,lovely_wilson BLOB);
INSERT INTO proficient_barrett VALUES (X'656E67726F7373696E675F636861636F', X'776F6E64726F75735F626F75726E65');
limbo> SELECT * FROM proficient_barrett
WHERE (
(
(
(
imaginative_etrebilal != X'6661766F7261626C655F636F726573'
OR
(imaginative_etrebilal > X'656E67726F7373696E675F6368616439')
)
AND
(
imaginative_etrebilal = X'656E676167696E675F6E6163696F6E616C'
OR
TRUE
)
)
OR
FALSE
)
AND
(
imaginative_etrebilal > X'656E67726F7373696E675F63686164F6'
OR
TRUE
)
);
engrossing_chaco|wondrous_bourne
```
@PThorpe92 I don't think we need the `parent_op` machinery at all, we
just need to not jump to the `jump_target_when_true` label given by the
parent if we are evaluating the first condition of an AND.
related: https://github.com/tursodatabase/limbo/pull/633
Reviewed-by: Preston Thorpe <cory.pride83@gmail.com>
Closes#698
This PR introduces counterexample minimization(shrinking) in the
simulator. It will require changes to the current structure in various
places, so I've opened it as a draft PR for now, in order to not
overwhelm the reviewers all at once.
- [x] Turn interactions plans into sequences of properties instead of
sequences of interactions, adding a semantic layer.
- [x] Add assumptions to the properties, rendering a property invalid if
its assumptions are not valid.
- [x] Record the failure point in a failing assertion, as shrinking by
definition works when the same assertion fails for a smaller input.
- [ ] Add shrinking at three levels,
- [x] top level(removing whole properties),
- [x] property level(removing interactions within properties),
- [ ] interaction level(shrinking values in interactions to smaller
ones).
- [ ] Add [marauders](https://github.com/alpaylan/marauders) as a dev
dependency, inject custom mutations to a testing branch for evaluating
the simulator performance.
- [ ] Integrate the simulator evaluation with the CI.
Closes#623
Per @penberg's suggestion on Discord, the `declare_scalar_functions!`
declarative macro has been replaced with a procedural one, allowing for
a much nicer API.
```rust
#[export_scalar]
#[args(0)]
fn uuid4_blob(_args: &[Value]) -> Value {
let uuid = uuid::Uuid::new_v4();
let bytes = uuid.as_bytes();
Value::from_blob(bytes.to_vec())
}
```
Closes#687
This PR adds the `load_extension` function, and allows for platform
agnostic arguments: e.g. `select
load_extension('target/debug/liblimbo_uuid');` omitting the file
extension.
Closes#680
## Purpose of this PR
- Add support for `createStatement` in `JDBC4Connection`
- Following works can use this statement to execute queries
## Changes
- Implement `createStatement` for `JDBC4Connection`
- Add `JDBC4Statement`
## References
- https://github.com/tursodatabase/limbo/issues/615Closes#693
...it is totally fine for a SQL query to fail as part of the simulation.
For example, if we attempt to create a table that already exists, the
expectation is that the query fails. No need to spam the logs.
Bug found by @alpaylan and described here: https://github.com/tursodatab
ase/limbo/issues/662#issuecomment-2589756954
The reason is that we were, as a bytecode optimization, marking
instructions as constant in places where it was not safe to do so. It is
ONLY safe to mark an instruction as constant if the register allocated
for the result of that instruction is allocated during the translation
of that expression.
In the case of e.g. `Unary(Minus, Number)` we were doing the following:
```
limbo> CREATE TABLE likable_fire (captivating_insolacion INTEGER,mirthful_shihab REAL);
limbo> INSERT INTO likable_fire VALUES (8358895602713329453, -7435384732.72567), (4233751081339504981, -6653311696.714637);
limbo> select * from likable_fire;
8358895602713329453|-6653311696.714637
4233751081339504981|-6653311696.714637
limbo> explain INSERT INTO likable_fire VALUES (8358895602713329453, -7435384732.72567), (4233751081339504981, -6653311696.714637);
addr opcode p1 p2 p3 p4 p5 comment
---- ----------------- ---- ---- ---- ------------- -- -------
0 Init 0 16 0 0 Start at 16
1 InitCoroutine 5 7 2 0
2 Integer 1783463725 2 0 0 r[2]=8358895602713329453
3 Yield 5 15 0 0
4 Integer 1454033237 2 0 0 r[2]=4233751081339504981
5 Yield 5 15 0 0
6 EndCoroutine 5 0 0 0
7 OpenWriteAsync 0 2 0 0
8 OpenWriteAwait 0 0 0 0
9 Yield 5 15 0 0
10 NewRowId 0 1 0 0
11 MakeRecord 2 2 4 0 r[4]=mkrec(r[2..3])
12 InsertAsync 0 4 1 0
13 InsertAwait 0 0 0 0
14 Goto 0 9 0 0
15 Halt 0 0 0 0
16 Transaction 0 1 0 0
<!-- Reg 3 evaluated in a loop, but marked as "constant" twice, resulting in the first value being overwritten! -->
<!-- The reason mark_last_insn_constant() breaks this is because different values are being evaluated into the -->
<!-- Same register in a loop -->
17 Real 0 3 0 -7435384732.72567 0 r[3]=-7435384732.72567
18 Real 0 3 0 -6653311696.714637 0 r[3]=-6653311696.714637
19 Goto 0 1 0 0
```
This PR removes `.mark_last_insn_constant()` from the affected places.
We should think about a small abstraction to prevent this going forward
Closes#679
This PR adds the start of an implementation of an extension library for
`limbo` so users can write extensions in rust, that can be loaded at
runtime with the `.load` cli command.
The existing "ExtensionFunc" `uuid`, has been replaced with the first
complete limbo extension in `extensions/uuid`
There is still considerable work to do on this, as this only implements
scalar functions, but this PR is already plenty big enough.
Design + implementation comments or suggestions would be appreciated
👍
I tried out using `abi_stable`, so that trait objects and other goodies
could be used across FFI bounds, but to be honest I didn't find it too
much better than this. I personally haven't done a whole lot with FFI,
or anything at all linking dynamically in Rust, so if there is something
I seem to be missing here, please let me know.
I added some tests, similar to how shell-tests are setup.
If anyone can test this on other platforms, that would be helpful as
well as I am limited to x86_64 linux here
Closes#658
