github dolthub/dolt v1.39.4
1.39.4

latest releases: v1.41.3, v1.41.2, v1.41.1...
one month ago

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
    Implemented dolt_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 the ForeignKeyCollection 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 to ForeignKeyCollection.GetMatchingKey() to allow the caller to control whether a resolved FK should match with unresolved FKs or not. This means ForeignKeyCollection.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 our rename 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 a ChildIter 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 in ON DUPLICATE expressions. It looks like either of the below options:
    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;
    This replaces the previous (now-deprecated) syntax:
    INSERT INTO tbl VALUES (1, 2) ON DUPLICATE KEY b = VALUES(b);
    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.
    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 in sql/expression/function/json doesn't depend on testify, 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

Don't miss a new dolt release

NewReleases is sending notifications on new releases.