...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
## Purpose of this PR
Change java bindings support from jdk version 17 to 8.
## Changes
- Mostly related to dependency version updates
- Replace java 8 non supported methods
## Reference
https://github.com/tursodatabase/limbo/issues/615Closes#678
## Purpose of this PR
- Set up on how to manage licenses in limbo project
## Changes
- Move all licenses under `licenses` directory in the root path
- Add `NOTICE.md`
- Update `CONTRIBUTING.md` to explain how to add licenses to project
## Reference
https://github.com/tursodatabase/limbo/issues/615Closes#677
This adds the missing parts of #668 which was just making the locks non-
blocking so they fail right away on conflict. Rustix was not very clear
on that, and the doc for `fcntl` didn't mention it, it was in the docs
for `flock`.
I have checked that this doesn't hang the test (🤦♂️).
Closes#676
## Purpose of this PR
- Add Nullability checks during compile time
## Changes
- Add `com.user.nullaway:nullaway` dependency for checking null issues
during compile time
- Related dependencie(`com.google.errorprone`) and plugin
`net.ltgt.errorprone` is added
- Because added dependencies has Apache 2.0 License, added NOTICE.md
under the root directory.
- Individual license for each dependency is placed under `licenses`
directory
## Note
- This PR has to be merged after
https://github.com/tursodatabase/limbo/pull/646
## Reference
- [Issue](https://github.com/tursodatabase/limbo/issues/615)
Closes#648
While working to include new json functions (related to #127) I noticed
that the program step code for json functions https://github.com/tursoda
tabase/limbo/blob/0dceb02ec04241b3772332853bcbfb9eb559adb9/core/vdbe/mod
.rs#L1346 was a bit different from scalar functions's code, where the
match to the inner function is nested https://github.com/tursodatabase/l
imbo/blob/0dceb02ec04241b3772332853bcbfb9eb559adb9/core/vdbe/mod.rs#L142
4
I added the same nesting to the json functions so it is more consistent
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#663
This shaves off `nix` as a dependency in core, which was only being used
in the io_uring backend for the `fcntl` advisory record locking. Since a
previous PR made `rustix` a dep not only for Mac but for any Unix, and
`rustix` also has `fcntl`, `nix` becomes redundant.
Furthermore, it reduces `libc` usage across core. The only remaining
uses are:
```rust
io_uring::opcode::Readv::new(fd, iovec as *const iovec as *const libc::iovec, 1)
io_uring::opcode::Writev::new(fd, iovec as *const iovec as *const libc::iovec, 1)
```
These two are a little ugly, but sadly the `io_uring` crate requires
both opcodes to take a `libc::iovec` while it doesn't export the type.
See tokio-rs/io-uring#259 for a request to use `std::io::IoSlice` or to
export the type directly.
Apart from those two, there are no other usages of libc, so if those are
resolved, we could also drop the dependency on libc.
Closes#668
This implements libSQL compatible Rust API on top of Limbo's core. The
purpose of this is to allow libraries and apps that build on libSQL to
use Limbo.
Closes#597
