-
Notifications
You must be signed in to change notification settings - Fork 16
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
feat: add implicit updates of channel records to update_user #734
Conversation
in order to refresh TTLs of all the router row data, allowing automatic garbage collection of inactive router records by Bigtable Closes SYNC-4221
…es in release builds)
13c2e12
to
fba5073
Compare
connected_at: ms_since_epoch() - (10 * 60 * 1000), | ||
..Default::default() | ||
})) | ||
let user = User::builder() |
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.
Sad that we can't call ..Default::default()
because the _channels
item isn't technically writable, but very happy to have a builder method instead.
@@ -201,6 +202,46 @@ fn to_string(value: Vec<u8>, name: &str) -> Result<String, DbError> { | |||
}) | |||
} | |||
|
|||
/// Parse the "set" (see [DbClient::add_channels]) of channel ids in a bigtable Row. |
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.
+1 on extracting these into functions. Thanks!
6d10d2c
to
438a35f
Compare
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.
Lgtm, just had a question about the check for the cell count.
fn channels_to_cells(channels: Cow<HashSet<Uuid>>, expiry: SystemTime) -> Vec<cell::Cell> { | ||
let channels = channels.into_owned(); | ||
let mut cells = Vec::with_capacity(channels.len().min(100_000)); | ||
for (i, channel_id) in channels.into_iter().enumerate() { |
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.
Is there a desire to check the size of challens
prior to iteration, or is it intended to be a processing limit at runtime while looping through? Just curious in case a check before iterating was valuable.
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, we're going to begin enforcing a max limit of channels shortly, which will probably end up changing this check #733
in order to refresh TTLs of all the router row data, allowing automatic garbage collection of inactive router records by Bigtable
Closes SYNC-4221
So this isn't too much code and doesn't appear to be generally all that annoying (yet), shall we go with this route? It saves us a couple extra db calls -- as we are already reading (at least requesting from bigtable) all channels in
get_user
.