Remove bidirectional nature of related items #172
Conversation
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
Related items have been treated as bidirectional after zotero@fbaa602. This means that if item A is one of related items for item B but not the other way around, item B would still be included in the list of related items for item A. This caused sync issue when one of two related items was deleted. Modifications to the non-deleted item are synced first, followed by the deletion. The dataserver would return the relation to the item that was about to be deleted after modification of the non-deleted item is handled. This would trick Zotero on the client side into believing that the relation to the deleted item still existed. More context: zotero/zotero#5486
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Related items have been treated as bidirectional after fbaa602. This means that if item A is one of related items for item B but not the other way around, item B would still be included in the list of related items for item A.
This caused sync issue when one of two related items was deleted. Modifications to the non-deleted item are synced first, followed by the deletion.
The dataserver would return the relation to the item that was about to be deleted after modification of the non-deleted item is handled. This would trick Zotero on the client side into believing that the relation to the deleted item still existed.
More context: zotero/zotero#5486