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
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
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
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

varun requested review of this revision.Nov 8 2022, 1:27 PM
services/identity/src/database.rs
335 ↗(On Diff #18240)

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 ↗(On Diff #18240)

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 ↗(On Diff #18240)

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 ↗(On Diff #18240)

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.