NoREC is a correctness property for testing optimizers, proposed by
Rigger and Su in [Detecting Optimization Bugs in Database Engines via
Non-Optimizing Reference Engine
Construction](https://www.manuelrigger.at/preprints/NoREC.pdf)
This PR adds a NoREC property to the tester.
Closes#973
I wanted to assist the current development in an up-to-date fashion,
this PR adds drop table(which is being implemented currently in
https://github.com/tursodatabase/limbo/pull/897) testing support to the
generator.
Unfortunately, we don't have feature flags in the simulator yet, so the
users should manually fix the generation probability in
`simulator/generation/plan.rs#L644` and
`simulator/generation/property.rs#L629`.
Closes#949
chrono has default features that are incompatible with some targets, such as non-js WebAssembly.
Removing the unused defaults allows limbo to compile to these targets
Hey! I've rebuilt the JSON path parser to make it easier to maintain and
catch more edge cases.
Main stuff:
- Removed pest dependency in favor of hand-written parser
- Better memory usage (pre-allocates space, use Cow)
- Handles quoted keys properly now
- Added tests for weird edge cases
- Added PPState (Shoutout ThePrimeagen)
Closes#970
Adds initial limited support for CTEs.
- No MATERIALIZED
- No RECURSIVE
- No named CTE columns
- Only SELECT statements supported inside CTE
Basically this kind of WITH clause can just be rewritten as a subquery,
so this PR adds some plumbing to rewrite them using the existing
subquery machinery.
It also introduces the concept of a `Scope` where a child query can
refer to its parent, useful for CTEs like:
```
do_execsql_test nested-subquery-cte {
with nested_sub as (
select concat(name, '!!!') as loud_hat
from products where name = 'hat'
),
sub as (
select upper(nested_sub.loud_hat) as loudest_hat from nested_sub
)
select sub.loudest_hat from sub;
} {HAT!!!}
```
I think we need to expand the use of `Scope` to all of our identifier
resolutions (currently we don't explicitly have logic for determining
what a given query can see), but I didn't want to bloat the PR too much.
Hence, this implementation is probably full of all sorts of bugs, but
I've added equivalent tests for ALL the existing subquery tests,
rewritten in CTE form.
Closes#920
## Changes
- AS-IS
- `LimboConnection` implements `Connection`
- `JDBC4Connection` implements `LimboConnection`
- TO-BE
- `LimboConnection` doesn't implement `Connection`. It is used to
represent connection to limbo only.
- `JDBC4Connection` implements `Connection` directly. Holds
`LimboConnection` in member field.
- This helps remove the complexity of java's `Connection` interface away
from `LimboConnection`. We can focus on implementing limbo's feature
inside `LimboConnection` and let `JDBC4Connection` handle the
interoperability with jdbc world.
## Reference
https://github.com/tursodatabase/limbo/issues/615Closes#916
I am on a bit of a mission to revisit a lot of the ref counting, this
was an easy first win.
It seems to be a linear path of function calls or hashmaps which can own
the completions directly, no cloning needed.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#912
This is an attempt to move towards #881. I am not sure this is the
direction you want to take. In any case, I thought I would take a crack
at converting `values` from `Record` to private and see how bad it would
be.
In the end, as you can see, it is not so bad. I think performance-wise
it shouldn't be a bad hit with Rust's zero-cost abstraction. Also,
during the process I noticed a couple improvements that could be made
here and there but I honestly wanted to start with something small
enough that wouldn't be too hard to review.
Anyway, let me know if this is really how you would like to proceed.
Closes#962
This PR aims to simplify text creation and to reduce allocation overhead
of creating a new OwnedValue::Text. Instead of creating Rc<String> every
time you need to create a text, you just pass the string slice and the
Rc<String> is created at the end. This change, at least on my machine,
has removed a lot of variability in the benchmarking performance, while
maintaining roughly the same performance.
Closes#961
