Page MenuHomePhabricator

[services][identity] db client method to get user public key
ClosedPublic

Authored by varun on Nov 8 2022, 1:13 PM.
Tags
None
Referenced Files
F3278040: D5569.diff
Sat, Nov 16, 8:08 AM
Unknown Object (File)
Mon, Nov 4, 12:43 AM
Unknown Object (File)
Mon, Nov 4, 12:43 AM
Unknown Object (File)
Mon, Nov 4, 12:42 AM
Unknown Object (File)
Mon, Nov 4, 12:42 AM
Unknown Object (File)
Mon, Nov 4, 12:28 AM
Unknown Object (File)
Fri, Oct 25, 5:18 PM
Unknown Object (File)
Fri, Oct 25, 5:18 PM

Details

Summary

first we use the user ID to get the associated item from the users table in DDB. then we try to find the device ID in the item's devices map, and if successful, return the device's user public key.

Depends on D5568

Test Plan

tested in the next diff when the getUserPublicKey RPC is callable

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

varun requested review of this revision.Nov 8 2022, 1:27 PM
services/identity/src/database.rs
335

why do we remove the item as part of parsing the attribute? seems a bit odd to be mutating a collection while searching through them.

services/identity/src/database.rs
335

get only returns a reference to the item, whereas remove returns the actual value. this lets us avoid cloning

325–340 ↗(On Diff #18236)
tomek added inline comments.
services/identity/src/database.rs
335

I'm not convinced that using confusing method is a good solution to work around borrowing issues. How the code would look like if we used get method?

This revision is now accepted and ready to land.Nov 10 2022, 4:48 AM
services/identity/src/database.rs
335

i don't really think it's confusing, and it seems like a common practice. jim was actually the one who suggested it a while ago. if we use the get method we have to clone the borrowed value. we use remove a lot in this module already, but i'm happy to change them to gets if you guys think that's better.