Introduced structs representing rows/items in the identity-devices DDB table.
Depends on D10153
Details
Details
None yet
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| services/identity/src/constants.rs | ||
|---|---|---|
| 69–70 ↗ | (On Diff #34363) | Used in D10216 |
| services/identity/src/database.rs | ||
| 52–53 ↗ | (On Diff #34363) | I've decided to create a submodule of database just not to mess this file more (it has 1.5k lines already and my code is 600 more in total) |
| services/identity/src/database/device_list.rs | ||
| 25–33 ↗ | (On Diff #34363) | Wondering if it wouldn't be better to introduce types like IdentityKeyInfo and PreKey and make this a nested structure: struct PreKey { prekey: String, prekey_signature: String } struct IdentityKeyInfo { key_payload: String, key_payload_signature: String, social_proof: Option<String>, } struct DeviceRow { pub user_id: String, pub device_id: String, pub device_type: DeviceType, pub identity_keys: IdentityKeyInfo, pub content_prekey: PreKey, pub notif_prekey: PreKey, } We could use proto-generated types directly, but I found this in our code - probably could reuse this and add From traits for AttributeValue (see two child diffs of this). From the perspective of DDB structure, this doesn't matter (we're not going to index on keys so no downsides). |
| services/identity/src/database/device_list.rs | ||
|---|---|---|
| 25–33 ↗ | (On Diff #34363) | nested structure makes sense to me |