This release contains backwards incompatible changes:

• Values in JSON fields that were edited on both sides of a merge are now automatically merged, when possible, using a new JSON merging algorithm. The current JSON merging algorithm supports merging object keys in edited JSON docs, but other changes, such as edits to arrays, will still result in data conflicts in the merge that must be manually resolved. If you want to opt-out of this JSON merging behavior, you can set the @@dolt_dont_merge_json session variable.

Per Dolt’s versioning policy, this is a minor version bump because these changes may impact existing applications. Please reach out to us on GitHub or Discord if you have questions or need help with any of these changes.

Merged PRs

dolt

• 7267: recursively walk the fields of structs
• 7242: sql shell prompt includes branch name
  Three changes to the dolt sql shell:
  • Show the branch you are on: mydb/main>
  • Show the workspace is dirty with a "*" in the prompt
  • Add color to the DB name, branch, and dirty status.
• 7230: Allow for three way merges to automatically resolve concurrent changes to a JSON object when the changes affect different keys.
  I recommend looking at one commit at a time.
  This PR implemented the "Primary Goal" outlined in this doc.
  Basically, when two branches in a merge both modify the same JSON value, but touch different keys, dolt should be able to automatically resolve the merge by doing a Three Way Merge that compares the value on both branches to the value at a common ancestor.
  This implementation deviates from the strategy outlined in the doc in one major way: when a branch contains an edit to a nested object, we don't run the diff or merge algorithms recursively. Instead, we generate a diff that contains a JSON path to the modified object. Doing this allows us to generate all the diffs in a single linear pass, and is still easy to reason about what changes are conflicts.
  We discussed only performing this merge on JSON objects below a certain size for performance reasons, but the size of the object isn't actually visible to the merge algorithm. Given that this algorithm only runs for rows that would otherwise have a merge conflict, all dolt merges that succeed before this PR should see zero performance impact from this change, so I'm not worried about performance.

go-mysql-server

• 2244: Feature: SYSDATE() function
  Adds support for the SYSDATE() function.
  Related to: #7270
• 2243: Fix context warn panics
  fixes: #7262
• 2238: [memo] RequiredIndex interface
  Some table nodes need to be executed as IndexScans with mandatory filters. The new interface makes this transparent to join planning.
  re: #7256
• 2216: Use indexes and lookups for cardinality estimates
  Cardinality estimation happens once after join reordering, indexing, and lookup join planning. The indexes and lookups help with result count estimates.

Closed Issues

• 7262: Panic when Using INNER JOIN with String in IN

Latency