## 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
seeing #660 made me realize I shouldn't have used `now` in any
circumstances in these tests, tolerance or not ;)
they should all be deterministic now
Closes#671
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.
## Purpose
- Make DriverManager aware of limbo connection
For example, we can now do as follows:
```java
try (Connection connection = DriverManager.getConnection("jdbc:limbo:sample.db")) {
assertThat(connection).isNotNull();
}
```
## Changes
- Add following .java files in order for the DriverManager to detect
Limbo
- JDBC.java
- JDBC4Connection.java
- LimboConfig.java
- LimboConnection.java
- LimboDataSource.java
## Reference
- This PR has to be merged after following
[PR](https://github.com/tursodatabase/limbo/pull/645)
- [Related issue](https://github.com/tursodatabase/limbo/issues/615)
Closes#646
Simplifies function signatures and allows attaching more context to
ProgramStatus on `translate::translate`, useful for value binding –
#607.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#670
This PR fixes#666
Limbo was treating all single byte integers properly in `core/types.rs`,
but when converted in `sqlite3_ondisk`, it was losing the sign for 8 bit
integers, treating them all as unsigned. Sqlite3 specifies in their file
format that the `1` record serial type is "Value is an 8-bit twos-
complement integer." https://www.sqlite.org/fileformat.html
We now properly match sqlite3's output
Closes#667
Give the user the option of choosing IO backend. There is only a
"syscall" backend, unless built for Linux with `#[cfg(feature =
"io_uring")]` which introduces `--io=io-uring`.
Right now, the choice has only been implemented for the CLI. Bindings
and such default to PlatformIO, except when an "in-memory" database has
been chosen.
Can be tested by running CLI with RUST_LOG=debug
Reviewed-by: Preston Thorpe <preston@unlockedlabs.org>
Closes#654
I was planning on starting work on index insertion, but realized we need
to know whether our cursor refers to a table or an index etc., so it
resulted in this refactoring work.
- `cursor_ref` now contains what _type_ of cursor it is (table, index,
pseudo, sorter)
- `program.cursors` is now `program.btree_table_cursors`,
`program.btree_index_cursors` etc and they are unboxed because dynamic
dispatch is no longer necessary
- Cursor trait removed -- 95% of the shit was btree specific anyway, so
I just moved them to `BTreeCursor`. In certain instructions in the VDBE
we expect a btree cursor and in others we expect a pseudo/sorter etc,
lets make that explicit.
- I also removed `BTreeCursor::get_new_rowid()` specific tests that
required macros to generate a mock implementation of the `Cursor` trait
-- main reason is I couldn't figure out how to reimplement this without
the trait, and the second reason is that I don't think we really need
those tests, AND the proc macro is constantly failing in my editor as
well and screwing up `rust-analyzer`
Closes#655
## Purpose of this PR
- Set rules for java naming, maybe we can add tests to automatically
test rules in the future
- For java methods, don't use underbar(IMO using camelcase for java
methods seems to be the common convention)
- If method names collide, append 0 at the back
## Reference
https://github.com/tursodatabase/limbo/issues/615Closes#645
Furthering work for JSON compatibility as described in #127, this change
adds support for the `json_error_position` function used to find the
error in invalid JSON values.
Closes#564
