Support the dolt_conflicts_resolve workflow when a table is dropped on one side of a merge.#9203
Closed
Support the dolt_conflicts_resolve workflow when a table is dropped on one side of a merge.#9203
dolt_conflicts_resolve workflow when a table is dropped on one side of a merge.#9203Conversation
…e other, record this as a schema conflict.
Contributor
|
@nicktobey DOLT
|
macneale4
requested changes
May 12, 2025
Contributor
macneale4
left a comment
macneale4
left a comment
There was a problem hiding this comment.
I think you should focus on making dolt_conflicts_resolve work before worrying about the dolt conflicts CLI command. Honestly we should migrate or deprecate the cli command.
At present This is the merge error I get:
db/dev*> CALL DOLT_CONFLICTS_RESOLVE("--ours", "TABLEFOO");
Unable to automatically resolve schema conflicts since data changes may not have been fully merged yet. To continue, abort this merge (dolt merge --abort) then apply ALTER TABLE statements to one side of this merge to get the two schemas in sync with the desired schema, then rerun the merge. To track resolution of this limitation, follow https://github.com/dolthub/dolt/issues/6616
|
|
||
| log_status_eq 1 | ||
| [[ "$output" =~ "conflict: table with same name deleted and modified" ]] || false | ||
| [[ "$output" =~ "CONFLICT (schema): Merge conflict in test" ]] || false |
Contributor
There was a problem hiding this comment.
Matching all the lines like this seems pretty frail. Would it make more sense to build these into the go engine tests?
Contributor
Author
|
Alright, I modified Unfortunately, the conflict resolution workflow seems to be broken for this case: Assuming that the branch containing the data edit is named When checking out
|
…nflicts because one side of the merge was deleted.
nicktobey
force-pushed
the
nicktobey/schemaconflict
branch
from
f271d38 to
21094c5
Compare
nicktobey
changed the title
dolt_conflicts_resolve workflow when a table is dropped on one side of a merge.
Contributor
|
@nicktobey DOLT
|
Contributor
Author
|
I'm going to close this. If a user requires the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The original behavior (reporting dropped tables as schema conflicts) was moved to its own PR: #9208
This PR contains the follow-up work to allow
dolt conflicts resolveto function in the presence of table drops. See below for examples where this doesn't currently work as expected.Currently, attempting to merge when a table has been drop on one branch and had its data modified on the other produces an immediate error that aborts the merge. This error does not necessarily have enough context to determine the affected table, which makes resolving the merge difficult.Given that we already handle a simultaneous drop + schema modification (by treating it as a schema conflict), we should be able to handle the simpler case of data modifications as well.Since dropping a table is technically a schema change, this should now get reported as a schema conflict, and pause the merge, allowing the user to querydolt_schema_conflictsfor more information.I'm not thrilled about the behavioral change observed in the BATS test "merge: ourRoot renames, theirRoot modifies the schema".What's happening there is that a renamed table is seen as a drop + a create. So the merge code sees a create with no conflicts, and attempts to add it to the same root as the original table (which is now in a conflict state.) Since both tables contain duplicate tags, this causes an error. This probably isn't what we want to happen, and we should figure out the intended behavior before merging this PR.