Skip to content
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

Make WriteAsync wait for changes asynchronously #1729

Merged
merged 4 commits into from
Jun 22, 2018
Merged

Conversation

fealebenpae
Copy link
Member

@fealebenpae fealebenpae commented May 4, 2018

Description

Fixes #1728

TODO

  • Changelog entry
  • Tests (if applicable)
  • Update PCL (if applicable)

@fealebenpae fealebenpae self-assigned this May 4, 2018
@fealebenpae fealebenpae requested a review from nirinchev May 4, 2018 15:57
Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

}).ContinueWith(_ => Refresh(), scheduler);
}).ContinueWith(_ =>
{
if (otherVersion == SharedRealmHandle.GetTransactionVersion())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be strict equality? I imagine if the current version is higher (for some reason) than the other version, we should still return?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I’ll change the comparison.

RealmChangedEventHandler handler = null;
handler = (sender, e) =>
{
((Realm)sender).RealmChanged -= handler;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit hazy on the subtleties of doing it like this (via the sender) rather than unsubscribing this.RealmChanged. Is it to avoid capturing this in the closure and what would the harm be if we did capture it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly - I didn’t want to capture this and create a reference cycle. If we capture it and the wvent never fires then the realm will leak.

/// Waits for the realm and outstanding objects to be updated to a newer version.
/// </summary>
/// <returns>An awaitable <see cref="Task"/>.</returns>
private Task WaitForChangesAsync()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope you don't mind a comment from an outsider. Could you consider making this public? And why the change in name compared to Refresh? I would expect it to be called RefreshAsync

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. I think I get it. You need to compare the current transaction version number with something, to avoid waiting in vane for a change that may never come. Is it not possible to query the realm for the highest transaction version seen?

@nirinchev nirinchev requested a review from tgoyne May 7, 2018 07:36
@nirinchev
Copy link
Member

@tgoyne I added you as a reviewer to give your opinion on the high-level approach and confirm whether it matches what we discussed, thanks.

@nirinchev nirinchev force-pushed the yg/refresh-async branch from 872bd28 to df3c670 Compare May 7, 2018 12:16
fealebenpae and others added 4 commits May 31, 2018 14:02
@nirinchev nirinchev merged commit 85f5e77 into master Jun 22, 2018
@nirinchev nirinchev deleted the yg/refresh-async branch June 22, 2018 10:36
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants