This makes io_uring the default in CLI, but makes it non-default in
core. Before, if one built CLI without io_uring, core still built with
it as it was a default feature. To accommodate for the change, all
bindings have been updated to select the feature, except for WASM which
has a separate fs implementation.
This also adds some #[cfg] and #[allow] to silence unused-* warnings,
which I discovered when testing with different features disabled.
Closes#942
`sqlite3-parser` spends a lot of time in `yy_reduce` assigning different
`enum YYMINORTYPE` members, and it suffers from bad performance because
the stack size of the enum is very large, and the size of individual
members varies wildly. This PR reduces the `YYMINORTYPE` stack size from
496 to 264 bytes and has the following effect:
Preparing statement:
```sql
Prepare `SELECT 1`/Limbo/SELECT 1
time: [620.37 ns 621.08 ns 621.79 ns]
change: [-17.811% -17.582% -17.380%] (p = 0.00 < 0.05)
Performance has improved.
Prepare `SELECT * FROM users LIMIT 1`/Limbo/SELECT * FROM users LIMIT 1
time: [1.2215 µs 1.2231 µs 1.2248 µs]
change: [-12.926% -12.627% -12.272%] (p = 0.00 < 0.05)
Performance has improved.
Benchmarking Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...: Collecting 100 samples in estimated 5.0152 s (
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
time: [3.1056 µs 3.1096 µs 3.1138 µs]
change: [-13.279% -12.995% -12.712%] (p = 0.00 < 0.05)
Performance has improved.
```
Execute (mainly to check for regressions):
```sql
Execute `SELECT * FROM users LIMIT ?`/Limbo/1
time: [402.19 ns 402.75 ns 403.36 ns]
change: [-3.4845% -2.4003% -1.6539%] (p = 0.00 < 0.05)
Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/10
time: [2.7920 µs 2.7977 µs 2.8036 µs]
change: [-1.3135% -1.0123% -0.7132%] (p = 0.00 < 0.05)
Change within noise threshold.
Execute `SELECT * FROM users LIMIT ?`/Limbo/50
time: [13.577 µs 13.633 µs 13.690 µs]
change: [-1.7709% -1.3575% -0.9563%] (p = 0.00 < 0.05)
Change within noise threshold.
```
Closes#936
Added `had_true: bool` to `Parser` to track the state of error
encounter, this will be set to `true` once we encounter an error.
If `had_error` is set to true we early return `Ok(None)`.
`FallibleIterator` works in the following way [when `next()`
returns](https://docs.rs/fallible-iterator/latest/fallible_iterator/trai
t.FallibleIterator.html#tymethod.next):
- `Ok(Some(item))` if there's a valid next item.
- `Ok(None)` if the iteration is complete.
- `Err(e)` if there's an error.
I have also added a unit test to check the above contract holds when
parsing `SELECT FROM foo`.
After the fix:
```
limbo> SELECT FROM foo;
× near "FROM": syntax error at (1, 12)
╭────
1 │ SELECT FROM foo;
· ▲
· ╰── syntax error
╰────
```
Closes#865
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#879
Since we are already round robin'ing our `iovecs` in the same way, and
the map will never be larger than MAX_IOVECS, we can remove the cost of
hashing and keep o(1) lookups.
Closes#922
Fixes three bugs:
- When a transaction commits, it should:
1. set the end timestamp of the old version to its own **end
timestamp**,
2. set the begin timestamp of the new version to its own **end
timestamp**
* we were erroneously setting it to the transaction's begin
timestamp. see https://www.cs.cmu.edu/~15721-f24/papers/Hekaton.pdf page
299 diagram.
- When checking for write conflicts, the system should ignore versions
that the transaction cannot see. We were checking for write conflicts
before visibility, allowing a tx to always see the latest committed
version and to always overwrite it, since latest committed versions dont
have an end timestamp.
- When checking for write conflicts, the _presence_ of an end timestamp
should always indicate that it is not the latest version and thus a
newer committed version exists, forcing the transaction to abort.
see https://www.cs.cmu.edu/~15721-f24/papers/Hekaton.pdf page 301
section 2.6. Updating a version
Reviewed-by: Pekka Enberg <penberg@iki.fi>
Closes#927
This is especially useful if you frequently run SQL query like `SELECT *
...`.
## Before
```
limbo> .mode pretty
limbo> select 123 as column1, 'Hello world' as column_2;
+-----+-------------+
| 123 | Hello world |
+-----+-------------+
```
## After
```
limbo> .mode pretty
limbo> select 123 as column1, 'Hello world' as column_2;
+---------+-------------+
| column1 | column_2 |
+---------+-------------+
| 123 | Hello world |
+---------+-------------+
```
---
In the future, if limbo adds a method like `.decl_type()`, we can also
display the data type.
###### DuckDB
```
D select 123 as column1, 'Hello world' as column_2;
┌─────────┬─────────────┐
│ column1 │ column_2 │
│ int32 │ varchar │
├─────────┼─────────────┤
│ 123 │ Hello world │
└─────────┴─────────────┘
```
Closes#925
This PR enables the generation of delete statements in the simulator.
There is still some work to do(I would like to add delete a specific
property).
This version currently hits a corruption error with seed
`3270937128460682661`, if anyone could debug it and let me know if it's
the generation that's wrong or the delete code has a bug, I would be
very grateful.
Closes#921
We have been working with a very small subset of SQL so far. As a rather
lightweight next phase, I propose that we make the generated queries
more realistic, slowly converging into the type definitions in
`limbo/core`. This PR will gradually implement such advances, the first
commit demonstrates how `LIMIT` is added to `SELECT`.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#793
Hi! This is my first PR on the project, so I apologize if I did not
follow a convention from the project.
#127
This PR implements json_quote as specified in their source:
https://www.sqlite.org/json1.html#jquote. It follows the internal doc
guidelines for implementing functions. Most tests were added from sqlite
test suite for json_quote, while some others were added by me. Sqlite
test suite for json_quote depends on json_valid to test for correct
escape control characters, so that specific test at the moment cannot be
done the same way.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Sonny (@sonhmai)
Closes#763
## Purpose of the PR
- As bindings/java is just a library, we shouldn't have to add specific
library dependency(such as slf4j) to itself
- In order to load bindings/java to 3rd party software(such as
Datagrip), we shouldn't provide a library with slf4j included
## Changes
- Remove slf4j, logback dependency and files
- Add custom logger implementation
## ETC
We can now connect to Datagrip(but there are some errors though)
## Reference
[Issue](https://github.com/tursodatabase/limbo/issues/615)
Closes#915
## Purpose of this PR
- Implement basic functionality of `PreparedStatement`
- `connection.prepareStatement(...)`
- `setNull`, `setBoolean`, `setInt`, `setDouble` ...
## Changes
- Add binding functions in rust side
- Implement `JDBC4Connection`'s `prepareStatement(sql)`
- Implement basic methods of `JDBC4PreparedStatement`
## TODO
- We can improve the performance of batching the binding operations(and
not execute immediately). For example, we can defer calling limbo's
`bind_at` when query is actually executed.
## Reference
[Issue](https://github.com/tursodatabase/limbo/issues/615)
Closes#913
