Update database with feature level etc. on each register #458
Comments
gnprice
added
a-api
|
Another effect of this is that it will serve as an early small trial run of the sort of code changes we'll need for #477, because it'll involve writing changes into the database in tandem with making them in our Dart data structures. |
I've just sent #526, built around one commit from that branch but then with 14 other commits of followups it led to. I've also rebased the branch as a whole and updated the rest of it a bit, and have it still as a draft branch. |
This is the first in a series of steps toward making [PerAccountStore.handleEvent] an async method. We'll need that in turn in order to let it start saving changes to disk when applicable, like for #458, and having both it and its caller, [UpdateMachine.poll], wait for the result rather than barreling ahead to make other changes concurrently. This change comes first because when we make `handleEvent` async, we'll want to make sure all its call sites properly wait for it to finish; and when that requires changing the caller to an async method, we'll want to do the same for *its* call sites, recursively. To keep the changes manageable to read and review, we'll make separate commits for each method, except local helpers with only a handful of call sites. The callers have to go before the callees in order to keep the commits coherent, so we start with this transitive caller.
With #458, we'll want this method to write changes to the database on certain events, to update the metadata we keep about the user's Zulip servers. When it does that, we'll want it to wait for that write to finish before it moves on to make other changes, and for its caller [UpdateMachine.poll] to similarly wait. That saves us from having to worry about potential races if some later event also wants to make database changes while the first changes haven't finished yet. It also gives us a good foundation for generally not showing the user a confirmation that some change has been made until we've actually saved the change. So to do that, we'll need the method to be async, and to return a Future which its call sites should wait for. That's this commit. It completes a series where we did the same thing for its callers, recursively.
|
In baea6d7 / #701 I wrote that with this issue #458 we'd want That wasn't quite right (or was imprecise, I guess, depending how one reads "with"): this issue only needed us to write such changes on register, not on any events. Hence this issue was completed last year, while we don't yet actually write any database changes caused by events (cf #1327 (comment)). The part that will call for database changes in handling events is when we handle |
On the Account class, corresponding to a row in our local database, we have several fields for values that may in reality change over time: most notably
zulipFeatureLevel, alsozulipVersionandzulipMergeBase.Currently we take the values of those fields when first logging in, and don't ever update them later. We should do so. In particular when we have compatibility logic that conditions on
zulipFeatureLevel, that will allow that logic to correctly use the server's current version rather than the version it had when we first logged in (perhaps months ago). Discussion here:https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/zulipFeatureLevel.20out.20of.20sync/near/1708193
Specifically this issue is for updating these values using the
registerQueueresponse. We should also do so onrestartevents; that's tracked as part of #135.I have a draft branch for this which I wrote one morning a few months ago and then didn't finish. (That branch handled
restartevents, which aren't so much a priority in themselves, but most of the work involved was for the ability to update account records in the database at all.)The text was updated successfully, but these errors were encountered: