-
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
Js/sectioned notification #5926
Conversation
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 fix feels off to me somehow, but I couldn't come up with anything that wasn't just more complicated for no benefit.
m_previous_key_to_index_lookup.clear(); | ||
m_prev_section_index_to_key.clear(); |
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.
I think it might make more sense to assert that these are empty rather than clearing them? If they're non-empty then something's gone wrong.
coordinator->on_change(); | ||
|
||
REQUIRE(callback_count == 0); |
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.
Adding a advance_and_notify(*r);
and expecting one call here makes this test a bit clearer IMO. I was briefly confused into thinking that it was checking the changeset from the initial notification rather than the second notification below.
TBH, I'm not well pleased with this fix either. This was my introduction to the sectioned results code and it was difficult to get into. This fix was the minimal thing I found to solve the user's bug report, because I didn't feel like doing a redesign. I suspect there are further bugs lurking if the sectioned results computes sections based off a linked property but I don't know if we officially support that anyways. |
…callback() If the SectionedResults had been previously evaluated, reset_section_callback() would leave it in an inconsistent state where m_has_performed_initial_evalutation was false but the previous run info was non-empty. #5926 introduced some assertions that now fail when this happens, but I suspect the actual behavior was also broken before that.
…callback() (#5965) If the SectionedResults had been previously evaluated, reset_section_callback() would leave it in an inconsistent state where m_has_performed_initial_evalutation was false but the previous run info was non-empty. #5926 introduced some assertions that now fail when this happens, but I suspect the actual behavior was also broken before that.
…nification * origin/master: (22 commits) Fix a race condition in error reporting for async open (#5968) Updated release notes version bump to 12.11.0 Fix a deadlock with simultaneous sync and nonsync commit notifications while tearing down RealmCoordinator (#5948) Track the last line seen and report it when there's an uncaught exception Verify that the same key is used when opening multiple DBs for a file Add stricter checks for valid reads on encrypted files Run core tests with encryption enabled on windows (#5967) Fix assertion failures after calling SectionedResults::reset_section_callback() (#5965) Add sync integration test for in-memory mode (#5955) Added realm core version to app login request (#5961) The client sending too much data is now reported as a ProtocolError::limits_exceeded (#5956) Updated release notes release core v12.10.0 Fix C-API for realm_object_get_parent (#5960) fixed a bug in recovery when copying embedded lists with a single link property prefix in the path (#5957) Js/sectioned notification (#5926) Use named apikey callbacks Fix IN query with TypedLink as left operator Fix a use-after-free in client reset when the original RealmCoordinator is gone (#5949) ...
Fixes #5912
A sectioned results stores a cached map of previous state to report what changed in
m_prev_section_index_to_key
. This is refreshed when sections are calculated which happens if theResults::has_changed()
returns true. The bug here is that if the first modification is on a linked property (changes are reported through links up to 4 layers deep) then the results has not actually changed, even though there is a change notification triggered on them. This means thatcalculate_sections
has only run once and it doesn't have any initial values form_prev_section_index_to_key
yet. The solution here is to set the previous values to the initial sections if it is known to be the first run.☑️ ToDos