Skip to content

Option to skip deletion of records on a case-by-case basis #49

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

Closed
glennmatthews opened this issue Apr 8, 2021 · 1 comment
Closed
Assignees
Labels
status: accepted This issue has been accepted by the maintainers team for implementation

Comments

@glennmatthews
Copy link
Collaborator

Environment

  • DiffSync version: 1.3.0

Proposed Functionality

Add a model flag that can be used to control whether an unmatched model class or instance will trigger deletion (and/or creation) of records when a sync operation is run.

Use Case

The existing global IGNORE_UNMATCHED_DST flag is not sufficiently granular as it applies to all records and all models. In some cases that may be adequate, but in others there needs to be per-model or even per-record control over this behavior -- for example, an application may not wish to delete unmatched Device records (perhaps a device is temporarily offline and hence not included in the source data), but may still wish to delete unmatched Interface records (as they reflect incorrect information about existing devices).

@dgarros dgarros added status: accepted This issue has been accepted by the maintainers team for implementation type: major feature and removed enhancement labels Jun 18, 2021
@FragmentedPacket FragmentedPacket self-assigned this Oct 7, 2021
@FragmentedPacket FragmentedPacket removed their assignment Nov 12, 2021
@dgarros dgarros self-assigned this Dec 16, 2021
@dgarros dgarros mentioned this issue Dec 16, 2021
3 tasks
@dgarros
Copy link
Contributor

dgarros commented Jan 25, 2022

@glennmatthews I think this has been fixed by #87

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: accepted This issue has been accepted by the maintainers team for implementation
Projects
None yet
Development

No branches or pull requests

3 participants