dolt 1.29.7

[Porkepix]

Created by brew bump

---

Created with brew bump-formula-pr.

Details

release notes

# Merged PRs
dolt

7191: Correctly resolve merge conflicts for types where two values with different representations can compare equal.

Prior to this PR, we used the column's comparison operator when attempting to detect if concurrent changes to a column could be resolved during a merge operation.

However, this can cause a problem when a type has two different representations that compare equal.

Some types have different representations that compare equal but can exhibit different behavior. For example, strings in a case-insensitive text column compare equal but behave differently when used in a context with a different collation and when displayed to the user. In this case, the merge algorithm should not consider them equal.
Other types have different representations that compare equal and exhibit identical behavior. For example, we store Decimal types as a (integer, exponent) pair, but we don't normalize this pair. So pairs like (45, 1), (450, 0), and (4500, -1) are all indistinguishable, including comparing equal. Since there's no way to distinguish these and the user should not have to know or care which representation is used, there is no danger in resolving potential merge conflicts by simply choosing a value. However, care must be taken that the same value is used regardless of the direction of the merge, in order to guarentee that the final table hash is the same.

In order to accomplish both of these, this PR does two things:
Forces the three-way merge algorithm to use a default comparator instead of the table's comparator. This defaults to a binary collation for strings.
In the event that a merge conflict is auto-resolvable because the two values being assigned are equal to each other, sort them and use the higher one instead of choosing one branch arbitrarily.


7181: Warning for nonsense variables in config

Prints a warning if any nonsense variables are found in global or local config files whenever any CLI command is run. Also restricts users from adding any nonsense variables with dolt config --add or dolt config --set.

Resolves: Fail when there is nonsense in config_golbal.json dolthub/dolt#7165

go-mysql-server

2210: sql/planbuilder: Update join defaults are not prefixed, need individual table schemas to resolve

Updates need to resolve default expressions. The input definitions for update joins include the total join output columns. If two of those columns have the same name, the target table's unqualified default expression will throw an "ambiguous column" error. We partition the update join schemas/column definitions to sidestep the error.

The case where this is problematic is ALTER COLUMN expressions, where only the columns being modified are scoped for some reason. In those cases, I create a new scope with the source table schema to provide the full set of underlying column definitions. There is probably a whole class of virtual columns/column default bugs related to the way we resolve alter statements.
2206: guard ctx.Span again

guard ctx.Span with nil check dolthub/go-mysql-server#2203 again, because it was overwritten

fixes Previous panic concerning CASE WHEN dolthub/dolt#7182 again
2205: use entire lateral scope when indexing RangeHeapJoin

RangeHeapJoins looked at the lateral join scope when assigning indexes.

However, we never tested nested joins for this case, leading to Query results are not as expected dolthub/dolt#7177

What made the error more apparent was the string in the left scope that would result in empty results when doing lookups into the right tables. The fix was to look at the whole lateral scope when indexing RangeHeapJoins

fixes Query results are not as expected dolthub/dolt#7177
2188: support on update current_timestamp

This PR adds support for handling and executing ON UPDATE column expressions, which are triggered when an update is applied to any column in the row.

TODO:

we support now() for default, but not the syntax for on update

fixes ON UPDATE CURRENT_TIMESTAMP in column definition does not update TIMESTAMP dolthub/dolt#6030



vitess

295: Allow inline column check constraint definitions to appear in any order

Previously, an inline column check constraint could only appear as the very last option for a column definition. This change allows it to appear in other positions in the column definition. For example, this query now works:
create table t123 (c1 varchar(5) check (c1 in ('v1', 'v2')) NOT NULL);
Resolves: Error parsing CREATE TABLE with both CHECK and NOT NULL dolthub/dolt#7195
294: Allow SqlType to parse "CHARACTER" and add tests for every other possible type that could be passed in.

SqlType is a function in Vitess for normalizing every type name. It was missing an entry for the "CHARACTER" keyword.

I added tests that should verify every single valid type keyword in the grammar, so this shouldn't happen again.

Closed Issues

7195: Error parsing CREATE TABLE with both CHECK and NOT NULL
7080: Joins against columns with case insensitive collations sometimes compare the join condition as if they were case sensitive.
7177: Query results are not as expected
7165: Fail when there is nonsense in config_golbal.json
7186: Support SET PERSIST GLOBAL for Dolt system variables

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.