dolt 1.35.11

[BrewTestBot]

Created by brew bump

---

Created with brew bump-formula-pr.

release notes

# Merged PRs
dolt

7778: Bump mysql2 from 3.9.4 to 3.9.7 in /integration-tests/mysql-client-tests/node

Bumps mysql2 from 3.9.4 to 3.9.7.
7775: Allow updating conflict table even if the underlying table schema changed.

This is an old check from before we had schema merge. I'm convinced that it was never actually needed. This PR has the necessary changes in order to remove it.

It's important that the user is able to resolve data conflicts even if the table schema has changed, because otherwise it is not possible to manually resolve data conflicts after a schema merge.

This PR also contains some additional tests, some of which are currently disabled because of Inconsistent detection of merge conflict, depending on direction of merge. dolthub/dolt#7767 and Panic during schema merge dolthub/dolt#7762
7771: Don't generate new tags for column type changes

Currently, when a column's type changes to a new type family (e.g. changing from varchar to int), we assign a new column tag. This prevents us from easily identifying the column across type changes. For example:

If column X is renamed and then its type is later changed, we can't track it across the rename or type change anymore. This usage pattern removes the value that column tags were intended to provide.
If column X changes its type, we can't easily differentiate between column X being dropped and a new column X being added. Heuristically, we can look at all the data in the table if it's all exactly identical, then we know it's a rename, but this is a somewhat hacky heuristic that can become ambiguous in more nuanced cases. This currently causes us to generate incorrect SQL patch statements that drops the renamed column and adds a new column. If customers were to apply these incorrect patch statements, it would drop all the data from their existing column, instead of converting it to the new type. This affects dolt_patch() and dolt diff -r sql and also prevents us from generating correct DDL statements for binlog replication.

This PR changes schema alterations so that columns now retain their original column tag across type changes, which fixes the issues above.

A side effect of this change is that if a customer is working on a branch, creates a column, and changes its type, the tag won't match if the schema on another branch is updated to the final type change (i.e. without going through the initial/intermediary type). Code was originally added for this case (see: Cant merge and because dolt does not let me resolve conflicts  dolthub/dolt#3950), however, since then, we have added support for schema merging and this isn't an issue anymore. I've confirmed that we can successfully merge non-matching column tags, from both directions, and added a test for this case, too.

Longer-term, I agree we should continue exploring removing tags completely, but in the short-term, this fixes a correctness problem with SQL patch statement generation that binlog support needs.

Related to: Optimize SQL returned from dolt_patch() dolthub/dolt#6710 (comment)


7769: AUTO_INCREMENT columns have NOT NULL constraint

companion pr: improve DESCRIBE columns and auto_increment bugs dolthub/go-mysql-server#2467
7768: fix: fix function name
7731: [nbs] getMany read planning and parallelize

Add read planning for journal getMany so instead of doing randIO we get seqIO. SeqIO has a large effect for disk storage systems. Also parallelize getMany calls. The biggest change here is the semantics around how reading locks the journal file. Reads hold the journal lock for longer, which could lower write throughput in some cases. If we see evidence of this, we can do more work to limit the amount of time batch reads can interruptibly holding the journal lock.

go-mysql-server

2468: Remove session mutex, status variables atomic inc

Avoid concurrent ctx use in doQuery. I standardized the session status variables to uint64 to make it easier to have them be atomics. The return types for these variables in MySQL seem to be strings, so switching them from int640->uint64 seems OK. We could always change the presentation layer later. Removing the session mutex appears to be safe after these changes.
2467: improve DESCRIBE columns and auto_increment bugs

This PR makes it so our DESCRIBE statement is more correct when there are unique keys.

There's an edge case we miss:
create table t (i int not null, j int not null, unique key (j), unique key (i));
describe t;
In MySQL, UNIQUE KEY j is created before UNIQUE KEY i, so describe makes j as PRI.

In Dolt, we store indexes in a map and return them in order of index name, so we mark i as PRI.

There are skipped tests for this

Additionally, this adds the NOT NULL constraint to columns that are marked AUTO_INCREMENT.

partially addresses: First Unique Key in a keyless table should be represented as a primary key dolthub/dolt#2289
2465: projection schema finds default values

fixes: Schema of "Create table t SELECT * FROM tbl" drops default values when compared to MySql dolthub/dolt#6016
2464: skipping auto_increment on error tests

I was wrong, this is very broken in dolt.

Could not find a quick fix, so skipping tests to unblock auto-bumps.

reopens: Auto Increment increments despite error dolthub/dolt#3157

vitess

340: improving partition parsing

partially addresses: Parser support for PARTITION BY dolthub/go-mysql-server#2472
337: Consistently using pointer to AliasedValues in InsertRows interface, never values.

Once again, golang reminds me that a value type implementing an interface forces the pointer type to also implement the interface, and mixing the two messes up our runtime type reflection.

I changed all uses of the AliasedValues in InsertRows interface to be pointers so that we can interact with them consistently on the GMS side.

Closed Issues

3129: dolt login works with DoltHub, but not a DoltLab instance

[github-actions]

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