Merged PRs
dolt
- 7979: Allow pulling from a remote if the only changes are to ignored tables.
This loosens the restrictions for pulling from remotes: instead of requiring that there are no working changes, we allow working changes but only to ignored tables.
If there are conflicting changes to ignored tables (which is rare, since ignored tables shouldn't be pushed to remotes in the first place), this will still abort the pull later when it's computing the new root hash.
This is, IMO, better than what git does. Git will just overwrite the ignored files without warning. - 7977: integration-tests/bats: Add some waits on the remotesrv_pid exit for bats tests which spawn a background remotesrv.
Attempts to fix some observed flakiness in bats tests. - 7975: implemented dolt_hashof_db function
Implementeddolt_hashof_db()
function which returns the root hash of a database. - 7967: go/libraries/doltcore/remotesrv: grpc.go: Respect X-Forwarded-Proto when generating HTTP download links in the gRPC server.
Fixes #7961. - 7965: Bug fix: Allow unresolved FKs to merge with resolved FKs
Dolt foreign keys can be in a "resolved" or "unresolved" state. A resolved FK has resolved the table and columns it references, and contains unique identifiers for the referenced columns. An unresolved FK only knows the table and column names that it references. Because of these two states, the way Dolt matches FKs differs depending on whether each key is resolved or unresolved.
Dolt has logic (ForeignKeyCollection.GetMatchingKey()
) to match a resolved FK with an unresolved FK, but this function didn't support matching an unresolved FK with a resolved FK. That code assumed that theForeignKeyCollection
would always be from an ancestor root value and therefore it wasn't valid for the ancestor to be resolved, while a more recent root value was unresolved. However, since then, we have used this logic in our root merging logic that breaks that assumption.
In a multi-session environment, one client can create a table with an unresolved FK, then a second session can load that table, resolve the FK, and commit the changes to disk. If the first session still contains references to the unresolved FK, then when it goes to commit, Dolt's merge logic wasn't able to match the unresolved FK in the session with the resolved FK that was written to disk, and the FK constraints were silently dropped from the new table version.
This PR adds a new parameter toForeignKeyCollection.GetMatchingKey()
to allow the caller to control whether a resolved FK should match with unresolved FKs or not. This meansForeignKeyCollection.GetMatchingKey()
doesn't have to assume its receiver instance is a ForeignKeyCollection from an ancestor root value, and instead the caller is responsible for specifying which behavior is needed.
Related to #7956 - 7955: [types] cache frequently read value store chunks (like working set roots)
- 7952: Made drop table work with search path
go-mysql-server
- 2537: Update generated index names to match MySQL
A customer pointed out that when we add indexes with generated names, we don't generate the same names as MySQL. Specifically:- When a FK is added with an explicit constraint name, that name should be used to name the automatically created index, if one is created.
- Secondary indexes are named after the first column in the index in MySQL, not by joining all the columns together.
Customer issue: https://github.com//issues/7960 Dolt PR with test fixes: https://github.com//pull/7974 - 2536: Rename generated FK names when their table is renamed
Updates ourrename table
logic to match MySQL's behavior of updating auto-generated foreign key names to match the new table name.
Customer issue: #7959
Dolt companion PR: #7968 - 2535: Fix UPDATE JOIN matchedRows
fixes: #7957
Main question is how thorough we want to make the child iter check. Should all iterators implement aChildIter
interface? - 2534: Implement row alias expressions (
INSERT ... VALUES (...) AS new_tbl ON DUPLICATE x = new_tbl.x
)
When inserting values, the user can specify names for both the source table and columns which are used inON DUPLICATE
expressions. It looks like either of the below options:This replaces the previous (now-deprecated) syntax:INSERT INTO tbl VALUES (1, 2) AS tbl_new ON DUPLICATE KEY b = tbl_new.b; INSERT INTO tbl VALUES (1, 2) AS tbl_new(a_new, b_new) ON DUPLICATE KEY b = b_new;
Supporting both syntaxes together was non-trivial because it means there's now two different ways to refer to the same column. While he had an existing way to "redirect" one column name to another, this only worked for unqualified names (no table name), and it overrode the normal name resolution rules, which meant we would fail to detect cases that should be seen as ambiguous.INSERT INTO tbl VALUES (1, 2) ON DUPLICATE KEY b = VALUES(b);
Previously, we would implement references to the inserted values by using a special table named "__new_ins". I implemented this by keeping that as the default, but using the row alias instead of one was provided. We then create a map from the destination table names to column aliases, and use that map to rewrite expressions that appear inside the VALUES() function. - 2533: Table name validation folds strings
fixes: #7958 - 2532: Move
json_function_tests.go
and json tests that depend on it to their own package.
This ensures that non-test code insql/expression/function/json
doesn't depend ontestify
, which is a library that we only want to depend on for tests. - 2530: Bug Fix: Index name case-insensitivity
MySQL index names are case-insensitive, but GMS' memory implementation wasn't handling them that way. This makes index names case-insensitive.
Related to #7945
Closed Issues
- 7970: Add support for
DOLT_HASHOF_DB()
- 7957: Dolt returns wrong number of affected rows for UPDATE ... JOIN with clientFoundRows=true
- 7958: UPDATE ... JOIN fails for tables containing capital letters
- 7945: Dolt panics when renaming index containing capital letters
- 7944: Dolt panics on subquery in IF statement in procedure
Performance
Read Tests | MySQL | Dolt | Multiple |
---|---|---|---|
covering_index_scan | 2.11 | 2.97 | 1.4 |
groupby_scan | 13.22 | 17.32 | 1.3 |
index_join | 1.34 | 5.47 | 4.1 |
index_join_scan | 1.27 | 2.26 | 1.8 |
index_scan | 34.33 | 54.83 | 1.6 |
oltp_point_select | 0.18 | 0.52 | 2.9 |
oltp_read_only | 3.55 | 8.28 | 2.3 |
select_random_points | 0.34 | 0.83 | 2.4 |
select_random_ranges | 0.39 | 0.97 | 2.5 |
table_scan | 34.33 | 54.83 | 1.6 |
types_table_scan | 77.19 | 139.85 | 1.8 |
reads_mean_multiplier | 2.2 |
Write Tests | MySQL | Dolt | Multiple |
---|---|---|---|
oltp_delete_insert | 8.13 | 6.21 | 0.8 |
oltp_insert | 3.82 | 3.02 | 0.8 |
oltp_read_write | 8.58 | 15.0 | 1.7 |
oltp_update_index | 3.89 | 3.13 | 0.8 |
oltp_update_non_index | 3.89 | 3.07 | 0.8 |
oltp_write_only | 5.47 | 6.55 | 1.2 |
types_delete_insert | 7.7 | 6.79 | 0.9 |
writes_mean_multiplier | 1.0 |
TPC-C TPS Tests | MySQL | Dolt | Multiple |
---|---|---|---|
tpcc-scale-factor-1 | 98.38 | 26.01 | 4.0 |
tpcc_tps_multiplier | 3.8 |
Overall Mean Multiple | 2.33 |
---|