-
Notifications
You must be signed in to change notification settings - Fork 29
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
Implement DiffSyncModelFlags.NATURAL_DELETION_ORDER. #220
Conversation
456670e
to
3e79a6a
Compare
3e79a6a
to
58f4806
Compare
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.
to me looks good, but I would make it the default (and sole) behavior
so @chadell your recommendation would be to drop this into 2.0 and make a backwards-incompatible change, changing the flag to be the default? |
as I see it, this seems more a bugfix than a feature as this deletion mode is the one I would expect by default. Actually, I don't see the other use case. So, my approach would be to do not even define a flag for it. |
In agreement with Christian, it seemed odd to me to have this as a flag. In my mind, it should be handled the same way that order children is handled. https://diffsync.readthedocs.io/en/latest/core_engine/02-customize-diff-class.html?#change-the-order-in-which-the-element-are-being-processed |
Unfortunately you can't achieve this behaviour from this MR in a custom |
My plan is now:
|
Closes #97. Implement
DiffSyncModelFlags.NATURAL_DELETION_ORDER
which handlesDiffSyncAction.DELETE
elements differently by first deleting their children recursively before handling their parents.Open points