-
Notifications
You must be signed in to change notification settings - Fork 168
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
RCORE-2175 RCORE-2176 RCORE-2182 RCORE-2083 Fix several problems with object removal and links #7830
Conversation
Pull Request Test Coverage Report for Build james.stone_561Details
💛 - Coveralls |
CI caught another bug in the BPNODE = 4 configuration where the wrong backlinks were being removed. I think I fixed it as well, but I plan to add more tests next week. |
a5e874f
to
d7b16c8
Compare
Pull Request Test Coverage Report for Build james.stone_563Details
💛 - Coveralls |
d7b16c8
to
8b65927
Compare
Pull Request Test Coverage Report for Build james.stone_564Details
💛 - Coveralls |
6304527
to
a23556e
Compare
Pull Request Test Coverage Report for Build james.stone_566Details
💛 - Coveralls |
CHANGELOG.md
Outdated
@@ -6,7 +6,10 @@ | |||
|
|||
### Fixed | |||
* <How do the end-user experience this issue? what was the impact?> ([#????](https://github.com/realm/realm-core/issues/????), since v?.?.?) | |||
* None. | |||
* Fixed a change of mode from Strong to All when removing links from an embedded object that links to a tombstone. This affects sync apps that use embedded objects which have a `Lst<Mixed>` that contains a link to another top level object which has been deleted by another sync client (creating a tombstone locally). In this particular case, the switch would cause any remaining link removals to recursively delete the destination object if there were no other links to it. ([#7828](https://github.com/realm/realm-core/issues/7828), since 14.0.0-beta.0) | |||
* Fixed `Table::remove_object_recursive` which wouldn't recursively follow links through a single `Mixed` property. ([#7829](https://github.com/realm/realm-core/issues/7829), likely since the introduction of Mixed) |
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.
This maybe goes under Internal since we don't actually expose remove_object_recursive().
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.
Valid point. It is part of core's public API, so I wasn't sure if this feature was exposed by any SDK or not.
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.
Very nice. I realize that using ObjKey parameters to hold something that does not actually identify an Obj was wrong. I have made #7852 as a PR to this PR. It introduces a new type - RowKey that can hold those internal keys, You are welcome to merge it if you like it.
Pull Request Test Coverage Report for Build james.stone_571Details
💛 - Coveralls |
I discovered these when inspecting the code while investigating #7594
The first issue appears to have been a mistake, and was introduced by #6766
I don't know of any reports of the wrong objects being deleted so hopefully this is niche enough that nobody has been affected, but on the other hand maybe it is related to some of the
Key 'Number' not found in '<Class Name>'
exceptions we have seen because unexpected objects are being deleted.The second issue is more benign, as fewer objects than expected may be deleted. The main thing there is that the state shouldn't have been ignored, and we already had a method for handling this.
The third issue was found due to CI running the new tests in the BPNODE=4 configuration. This uncovered a few other places in the code that had the same mistake: using the cluster local key instead of the "real" key. I renamed the variables there to hopefully make it clearer, and to avoid this mistake in the future.
The randomized testing that I added to cover the changes for the nested list/dictionary cases happened to trigger yet another bug which is the collapse/rejoin of clusters with nested collections and links.
Fixes #7828, #7829, #7839, #7594
☑️ ToDos
bindgen/spec.yml
, if public C++ API changed