-
Notifications
You must be signed in to change notification settings - Fork 165
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
RNET-1083: Add support for progress estimate on progress notifications #3479
Conversation
This is just a draft PR in case we have some discussing to do. It's also built on top of a PR in core. |
I'm going to park this for now, as the core implementation is not yet finished, and we can't write reliable tests without it. |
# Conflicts: # wrappers/realm-core
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.
Looks good to me - I'd just prefer that we clean up the obsolete stuff in this PR already rather than merge it and have a follow-up PR that removes all the obsolete things as we prepare for 12.0
Completely removed obsolete |
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.
Looks good, though it'd be nice to add a test that is a bit more strict about the notifications. Particularly, we should have a test for the download direction, which we don't seem to at the moment.
Pull Request Test Coverage Report for Build 8630691641Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
This is going to get parked until the core PR on which it depends it has been merged.
|
# Conflicts: # wrappers/realm-core # wrappers/src/async_open_task_cs.cpp # wrappers/src/sync_session_cs.cpp
@nirinchev this is mergeable for me (I can fix the lint warning after your review 😁 ) |
/// The callback will, upon registration, store the total number of bytes to be transferred. When invoked, it will | ||
/// always report the most up-to-date number of transferable bytes out of that original number of transferable bytes. | ||
/// When the number of transferred bytes reaches or exceeds the number of transferable bytes, the callback will | ||
/// The callback will be active until the current transferable bytes are transferred. When invoked, it will always report the |
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.
it's a bit weird now to refer to transferred/transferable after these fields were removed. Also, it makes no sense any more for download direction. Probably, a good idea is to rephrase it in a way that it refers to snapshot committed version for upload on callback registration (that is essentially transferable bytes), and for download it is whatever server decides for the outgoing or next batch of changesets to catch up the client to the latest version.
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.
@kiburtse I agree with you, it's kinda imprecise.
Would you think the following will make sense?
The callback will be active:
- For uploads, until all the unsynced changesets available at the moment of the registration of the callback are sent to the server.
- For downloads, until the client catches up to the current server data (available at the moment of registration) or the next batch of changesets sent from the server.
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.
@nirinchev I'll fix the other two small things. I suppose this is the latest thing to agree on. Do you have input on this?
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.
@papafe looks good to me. The only additional consideration here is that this notion of "next batch of changesets" is very sync client implementation specific. I'm not sure how familiar sdk users are with this. Maybe it also raises the expectations a bit too much since in steady state this is not the case for sure because every download message is its own batch, and in general it's not defined as of now how it should behave with flexible sync and subscriptions change.
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.
Makes sense. I think I will change "changeset" to "data" to keep on the more generic side
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.
Looks good - there's a few lint warnings you could drive-by fix.
Realm/Realm/Handles/SessionHandle.cs
Outdated
{ | ||
var token = (ProgressNotificationToken?)GCHandle.FromIntPtr(tokenPtr).Target; | ||
token?.Notify(transferredBytes, transferableBytes); | ||
// This is used to provide a reasonable progress estimate until the core work is done | ||
double managedProgressEstimate = transferableBytes > 0.0 ? transferredBytes / transferableBytes : 0.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.
If transferable is 0, shouldn't progress be 1?
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.
Yes 👀
This PR:
ProgressEstimate
toSyncProgress
. It's a float value between 0.0 and 1.0 representing the estimate of the current progress.TransferableBytes
andTransferredBytes
inSyncProgress
as these values are not accurate (especially for flexible sync).GetProgressObservable
with flexible sync.Fixes #3478
TODO