Two recent reports from the forum:
Since the fix for issue 5099 merging two trees with overlapping XREFs won't work if these objects also have records in table wt_change. Fyi, a freshly imported tree has no records in table wt_change, these are only created through manual edits.
Prior to merging two trees, the set of overlapping XREFs of both trees is determined by the AdminService - function countCommonXrefs.
If overlapping XREFs are found, then at least one tree should be renumbered. The renumbering uses AdminService - function duplicateXrefs.
Renumbering a tree does not touch any records in table wt_change, but their XREFs are still taken into consideration by function countCommonXrefs. Imho this causes the reported issue.
Known work-around: export both trees to GEDCOM and import again. This has the side-effect of deleting all records in table wt_change for the imported tree.
These changes should fix the issue:
- Delete all
wt_change records referring to objects which are renumbered. Seems logical, since this is also done when an object is deleted.
- Do not take
wt_change records into consideration in function countCommonXrefs of the AdminService, as it was prior to fix of issue 5099. Side note: I don't understand why table wt_change is queried in the first place since pending changes are not copied over (or warned for) when merging.
Before I go implementing this and find a PR gets rejected: any thoughts or advice, Greg?
Two recent reports from the forum:
Since the fix for issue 5099 merging two trees with overlapping XREFs won't work if these objects also have records in table
wt_change. Fyi, a freshly imported tree has no records in tablewt_change, these are only created through manual edits.Prior to merging two trees, the set of overlapping XREFs of both trees is determined by the
AdminService- functioncountCommonXrefs.If overlapping XREFs are found, then at least one tree should be renumbered. The renumbering uses
AdminService- functionduplicateXrefs.Renumbering a tree does not touch any records in table
wt_change, but their XREFs are still taken into consideration by functioncountCommonXrefs. Imho this causes the reported issue.Known work-around: export both trees to GEDCOM and import again. This has the side-effect of deleting all records in table
wt_changefor the imported tree.These changes should fix the issue:
wt_changerecords referring to objects which are renumbered. Seems logical, since this is also done when an object is deleted.wt_changerecords into consideration in functioncountCommonXrefsof the AdminService, as it was prior to fix of issue 5099. Side note: I don't understand why tablewt_changeis queried in the first place since pending changes are not copied over (or warned for) when merging.Before I go implementing this and find a PR gets rejected: any thoughts or advice, Greg?