New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow updating conflict table even if the underlying table schema changed. #7775
Conversation
…chema change. This should always be safe, and is necessary in order to manually resolve data conflicts if there was a schema merge.
@nicktobey DOLT
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
}, | ||
Assertions: []queries.ScriptTestAssertion{ | ||
{ | ||
Skip: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to skipped?
It would be nice for this test to see the error, then turn autocommit off and successfully resolve the conflicts, then commit the merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's skipped because it triggers #7767. I added a comment explaining why its skipped.
This will probably be fixed if we get rid of column tags.
@nicktobey DOLT
|
@coffeegoddd DOLT
|
@coffeegoddd DOLT
|
@coffeegoddd DOLT
|
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 #7767 and #7762