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 https://github.com/dolthub/dolt/issues/7767 and https://github.com/dolthub/dolt/issues/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: https://github.com/dolthub/dolt/issues/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: https://github.com/dolthub/dolt/issues/6710#issuecomment-1734318087
• 7769: AUTO_INCREMENT columns have NOT NULL constraint companion pr: https://github.com/dolthub/go-mysql-server/pull/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: https://github.com/dolthub/dolt/issues/2289
• 2465: projection schema finds default values fixes: https://github.com/dolthub/dolt/issues/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: https://github.com/dolthub/dolt/issues/3157

vitess

• 340: improving partition parsing partially addresses: https://github.com/dolthub/go-mysql-server/issues/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