The join operator is also a stateful operator. It keeps the input deltas
stored in the state, for both the left and right branches of the join.
JOINs extract a join key, which is the values that were used in the
join's equality statement. That key is now our zset_id, and it points
to a collection of rows.
Ahead of the implementation of JOINs, we need to evolve the
IncrementalView, which currently only accepts a single base table,
to keep a list of tables mentioned in the statement.
Our code for view needs to extract the list of columns used in the view.
We currently extract only from "the base table", but once we have joins,
we need a more complex structure, that keeps the mapping of
(tables, columns).
This actually affects both views and materialized views: for views, the
queries with joins work just fine, because views are just aliases for
a query. But the list of columns returned by pragma table_info on the
view is incorrect. We add a test to make sure it is fixed.
For materialized views, we add extensive tests to make sure that the
columns are extracted correctly.
fixes#3199
I love running whopper in `chaos` mode. However, sometimes when the file
limit exceeds 1GB, it panics because whopper does not allow larger
files.
This patch changes this behaviour slightly:
1. Increased the file limit to 8GB and also added a soft limit of 6GB
2. The simulator shares a hashmap of `<file_name, file_size>` with the
IO
3. The IO layer updates the logical file size whenever it does inserts
4. In the sim we check the file size and if it exceeds the soft limit,
we stop
5. In chaos mode, this will move on to the next test
The panics can still happen, but they are largely reduced now.
Closes#3216
Adds `round`, `hex`, `unhex`, `abs`, `lower`, `upper`, `sign` and `log`
(with base) to the expression fuzzer.
Rounding with the precision argument still has some incompatibilities.
Closes#3160
When shrinking, the depending table should first start with the
dependencies from the overall property first. I broke this in my
previous Sim Connections PR.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3203
Nothing fancy yet, assuming you merge this I'll do this one next:
```
warning: function pointer comparisons do not produce meaningful results since their addresses are not guaranteed to be unique
--> core/types.rs:403:5
|
398 | #[derive(Debug, Clone, PartialEq)]
| --------- in this derive macro expansion
...
402 | pub step_fn: StepFunction,
| ^^^^^^^^^^^^^^^^^^^^^^^^^
403 | pub finalize_fn: FinalizeFunction,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: the address of the same function can vary between different codegen units
= note: furthermore, different functions could have the same address after being merged together
= note: for more information visit <https://doc.rust-lang.org/nightly/core/ptr/fn.fn_addr_eq.html>
```
And fix a test failure that I resolved in Python (specific to macOS
hosts). Basically this PR is putting my toe in the water to see how open
you are to contribs!
Closes#3211
This is wip but since I have it working on a single connection maybe
this is worth to review right now.
I haven't done any header work right now for the on disk format, but
instead I've basically added the skeleton for logical log transactions
on MVCC to work.
**before merging this pr I have to remove cherry picked commit from
https://github.com/tursodatabase/turso/pull/3156**
Closes#3158
closes#3206 and https://github.com/tursodatabase/turso-go/issues/21
What happens is the coroutine overwrites the program state.. so the
`RETURNING` result columns are from the `translate_select` that happens
when we insert multiple rows.
```rust
let result = translate_select(schema, select, syms, program, query_destination, connection)?;
// overwrites program.result_columns
```
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3208
