This solves the issue of having weird ansi escape codes when creating
github issues for the simulator
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#1745
our AWS nightly sim looks for a line 'simulation failed:' in the process
output to capture context for the github issues it creates.
if the sim passes otherwise but integrity check fails, then this log
line must also be present there, otherwise the aws sim will panic due to
not finding a suitable line.
Closes#1716
our AWS nightly sim looks for a line 'simulation failed:' in the process
output to capture context for the github issues it creates.
if the sim passes otherwise but integrity check fails, then this log line
must also be present there, otherwise the aws sim will panic due to not finding
a suitable line.
This PR is a Drop-In replacement to the Predicate defined in the
Simulator. Predicate is basically the same as our ast::Expr, but it
supports a small number of the SQL expression syntax. By creating a
NewType that wraps ast::Expr we can tap into our already mostly
correctly defined parser structs. This change will enable us to easily
add generation for more types of sql queries.
I also added an ArbitraryFrom impl for ast::Expr that can be used in a
freestyle way (for now) for differential testing.
This PR also aims to implement Unary Operator logic similar to the
Binary Operator logic we have for predicate. After this change we may
need to adjust the Logic for how some assertions are triggered.
<s>Sometimes the `Select-Select-Optimizer` property thinks that these
two queries should return the same thing:
```sql
SELECT (twinkling_winstanley.sensible_federations > x'66616e7461737469625e0f37879823db' AND twinkling_winstanley.sincere_niemeyer < -7428368947470022783) FROM twinkling_winstanley WHERE 1;
SELECT * FROM twinkling_winstanley WHERE twinkling_winstanley.sensible_federations > x'66616e7461737469625e0f37879823db' AND twinkling_winstanley.sincere_niemeyer < -7428368947470022783;
```
However after running the shrunk plan manually, the simulator was
incorrect in asserting that. Maybe this a bug a in the generation of
such a query? Not sure yet. </s>
<b>EDIT: The simulator was correctly catching a bug and I thought I was
the problem. The bug was in `exec_if` and I fixed it in this PR.</b>
I still need to expand the Unary Operator generation to other types of
predicates. For now, I just implemented it for `SimplePredicate` as I'm
trying to avoid to bloat even more this PR.
<b>EDIT: I decided to just have one PR open for all the changes I'm
making to make my life a bit easier and to avoid merge conflicts with my
own branches that I keep spawning for new code.</b>
PS: This should only be considered for merging after
https://github.com/tursodatabase/limbo/pull/1619 is merged. Then, I will
remove the draft status from this PR.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1674
In the normal path, we properly fsync the wal file before beginning a
checkpoint. However when we forcefully checkpoint upon closing the
connection we miss this step.
Closes#1695
Implement recursive processing for compound SELECT statements by
dividing them into two components:
1. left: a vector containing a SELECT core and its associated compound
operator
2. right_most: the rightmost SELECT core in the compound statement
Based on the compound operator, we can determine how to process the
rightmost part and recursively handle the left component.
Following this refactor, we can seamlessly integrate support for
`INTERSECT` and `EXCEPT` operations.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1718
Closes#1717
We were incorrectly setting `moved_before` as `false` after checking for
unique constraint violation, but the reality is that after the
uniqueness check, we are already correctly positioned -- if no match was
found, the cursor is positioned at either:
a) no row, or
b) at the first entry that is greater than the key we are inserting.
This means we don't have to move anymore and can just insert.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1723
We were incorrectly setting `moved_before` as `false` after checking
for unique constraint violation, but the reality is that after the
uniqueness check, we are already correctly positioned -- if no match
was found, the cursor is positioned at either:
a) no row, or
b) at the first entry that is greater than the key we are inserting.
This means we don't have to move anymore and can just insert.
Adds an `#[instrument]` to many btree related functions. Also, when
debugging #1717 it would be impossible to debug as the 10Mb SeekKey
would be printed to my terminal making the experience miserable. The
debug implementation now truncates the Blobs and Strings when they are
too big to be useful.
Closes#1721
