You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
8311: [kvexec] fix more lookup bugs related to schema/projection inconsistencies
We were using the full table schema to index a covering index KV pair. The fix has to be sensitive to covering, non-covering, and keyless tables, which required extra tests on the GMS side to check all cases.
fixes: #8308
re: dolthub/go-mysql-server#2646
8303: Perf: Optimize SQL transaction commits in binlog replication applier
The binlog replication applier process is responsible for applying the replicated updates from a MySQL source to the Dolt replica. Previously, when committing SQL transactions after applying a change, the applier would attempt to commit on all known databases. This worked when the number of databases was small, but when the server is handling hundreds of databases, it adds noticeable and unnecessary delay. This change switches to use the dirty tracking data of the session to more efficiently commit to only the databases that have had changes applied.
Performance Comparison
The old SQL transaction commit logic scaled exponentially, while the new logic scales linearly.
Num Databases
Code Path
Replication Time (s)
100
Old
11.02
300
Old
144.34
500
Old
633.44
100
New
6.79
300
New
20.51
500
New
36.04
8294: Feature: Data conflict resolution during interactive rebase
When data conflicts occur during an interactive rebase, customers can now use Dolt's conflict resolution tools to resolve the conflicts and continue the rebase operation. Note that schema conflicts are not supported yet.
Example:
>select*from dolt_rebase;
+--------------+--------+----------------------------------+----------------------------+
| rebase_order | action | commit_hash | commit_message |
+--------------+--------+----------------------------------+----------------------------+
| 1.00 | drop | iumpo2t0hd6drcn11jo8osdack1jmafp | inserting row 1on branch1 |
| 2.00 | pick | us2uaji20dj77cnf1i2l698itr5392se | updating row 1on branch1 |
+--------------+--------+----------------------------------+----------------------------+> call dolt_rebase('--continue');
data conflict detected while rebasing commit us2uaji20dj77cnf1i2l698itr5392se (updating row 1on branch1).
Resolve the conflicts and remove them from the dolt_conflicts_<table> tables, then continue the rebase by calling dolt_rebase('--continue')
>select*from dolt_conflicts_t;
+----------------------------------+---------+---------+--------+--------+---------------+----------+----------+-----------------+------------------------+
| from_root_ish | base_pk | base_c1 | our_pk | our_c1 | our_diff_type | their_pk | their_c1 | their_diff_type | dolt_conflict_id |
+----------------------------------+---------+---------+--------+--------+---------------+----------+----------+-----------------+------------------------+
| us2uaji20dj77cnf1i2l698itr5392se | 1 | one | NULL | NULL | removed | 1 | uno | modified | B1dLxGtGIlHRKJo88tigpw |
+----------------------------------+---------+---------+--------+--------+---------------+----------+----------+-----------------+------------------------+> call dolt_conflicts_resolve('--theirs', 't');
+--------+
| status |
+--------+
| 0 |
+--------+> call dolt_add('t');
> call dolt_rebase('--continue');
+--------+-----------------------------------------------------+
| status | message |
+--------+-----------------------------------------------------+
| 0 | Successfully rebased and updated refs/heads/branch1 |
+--------+-----------------------------------------------------+
2644: Fix Integration Workflow
This makes a few changes to how the integration workflow is handled:
main is now merged into this PR before testing. Previously, we would just use the PR as-is, which created a situation where the main branch included changes that the PR had not yet merged in. This created an issue as Dolt and DoltgreSQL would expect some changes to be present that were not yet merged into the PR, causing compilation errors. By merging main, we bypass this. In addition, the workflow will automatically pass if a merge conflict is detected. I think this is fine, since conflicts must be resolved before the PR can be merged anyway. This does mean that some errors may not be caught for as long as merge conflicts against main exist.
We only pulled comments, and the PR description does not count as a comment. This made it seem a bit inconsistent with how PR detection was handled. This has now been added, and we're now doing a basic string search instead of using a JSON parser, as concatenating the comments and description does not result in a valid JSON object.
Workflow should automatically run when a comment is added, modified, or deleted. This was already supposed to happen, but the event structure differed between a comment and push in a subtle way, causing the workflow to immediately error and for the UI to continue displaying the previous run. This made it seem as though the workflow did not respond to comment updates.
Additional logging messages have been added, so it's easier to debug if something goes wrong in the future.
2641: Correctly handle indexes on virtual columns
Fixes #8276
Lots of small behaviors around virtual columns were not working correctly:
Adding an index on a virtual column triggered a table rebuild even when this wasn't necessary
Rebuilding a table that contained virtual columns could lead to incorrect results
Inserting into a table with a virtual column could update indexes incorrectly
Adding a generated column to the start of a table could lead to incorrect results
This PR adds tests for these cases and fixes them by tweaking the logic for projections on tables with generated columns.
Closed Issues
8308: Empty result set from query with INNER JOIN + WHERE
