Closed jkitching closed 10 months ago
Will take a closer look at this once 0.15.0
is released.
Thanks for the thorough writeup! The self.sync(True)
call was introduced in e8c38c45. I don't recall what the rationale was at that time.
This should be a low risk bugfix, though it might require users to be more intentional about handling exception.ResyncRequiredException
Thanks, @kiwiz =)
Calling
login()
orresume()
withsync=True
(default) results in a "resync": local changes are destroyed, and a full download is made.Using
resync=True
vs.resync=False
doesn't make any difference when the cachedstate
argument is not provided, since a full download needs to be made either way.But when providing a
state
argument with cached state of Keep notes, bothlogin()
andresume()
simply throw that state away and re-download. This is because, as mentioned above, the defaultsync=True
implies a "resync".To recap:
The current interface for providing a
state
(case B above) is a somewhat clunky user experience. Many users may believe their cached state is being used, when in fact it is just being thrown out the window.Even switching
sync=False
is insufficient, since it completely disables any kind of sync on login. So the only resort is case C, which follows up with a manualsync(resync=False)
call.Solution
Unless there is a specific reason for the above design, may I suggest that the
sync
argument inlogin()
andresume()
be changed to imply async(resync=False)
call instead ofsync(resync=True)
? (I.e. change theself.sync(True)
call inload()
.)In this case: