Private Preferences DB #946
Conversation
… np/create-private-preference-db
| @@ -0,0 +1,11 @@ | |||
| CREATE TABLE "private_preferences"( | |||
| -- The inbox_id the private preferences are owned by | |||
| "inbox_id" text NOT NULL, | |||
There was a problem hiding this comment.
We might not need an inbox_id since every item in this list will be for the person who is logged in they shouldn't be getting other peoples preferences.
There was a problem hiding this comment.
That sounds right. The entire DB is scoped to a single inbox
xmtp_mls/migrations/2024-08-07-213816_create-private-preference-store/up.sql
Outdated
Show resolved
Hide resolved
| -- The value of what has a preference | ||
| "value" text NOT NULL, | ||
| PRIMARY KEY (valueType, value) | ||
| ); |
There was a problem hiding this comment.
Want to make sure I'm reasoning about this correctly we will want a way to get the current consent state for a group or inbox id performantly so the primary key should be the value and the valueType so that you can fetch for type group and value group_id and get what the state is.
There was a problem hiding this comment.
That does feel like what we'll want at the end of the process. Very cheap to look up, has all the information a
One thing that was a struggle in the past is just making sure that we processed all the events in the correct order, so that if you allowed and then blocked the same group you'd get a consistent value in the end. What happens if you received a preferences event that you couldn't read before, but now you can? How do we rewind things so that you can rebuild the state? Maybe the right answer is to truncate this table and start from scratch in that scenario?
There was a problem hiding this comment.
does it make sense to make an index here, like we did for inbox id?
CREATE INDEX idx_value_type_value ON private_preferences(valueType, value ASC);
There was a problem hiding this comment.
My understanding is that the primary key made an index by default so we shouldn't need to add another index.
| -- The inbox_id the private preferences are owned by | ||
| "inbox_id" text NOT NULL, | ||
| -- Enum of the PRIVATE_PREFERENCE_TYPE (GROUP, INBOX, etc..) | ||
| "valueType" int NOT NULL, |
There was a problem hiding this comment.
I think we will want to have some logic in the code that says if type is ADDRESS find the inbox_id for that address and actually only store and fetch inbox ids. Probably a migration needed to convert all the V2 items to inbox ids.
| @@ -0,0 +1,11 @@ | |||
| CREATE TABLE "private_preferences"( | |||
There was a problem hiding this comment.
I wonder if we really want to call this "consent state".
Private preferences sounds more generic than what is really here. The schema is very specific to consent preferences (which is also the only kind we have right now).
| -- Enum of PREFERENCE_STATE (ALLOWED, DENIED, etc..) | ||
| "state" int NOT NULL, | ||
| -- The value of what has a preference | ||
| "value" text NOT NULL, |
There was a problem hiding this comment.
What do we think about calling it the "entity" just for clarity. I could read value to mean either "the thing that has a preference" or "the preference itself".
… np/create-private-preference-db
… np/create-private-preference-db
|
sans nits/lints + tests, it looks good to me |
| @@ -150,8 +150,12 @@ impl TryFrom<DmMembersProto> for DmMembers { | |||
|
|
|||
| fn try_from(value: DmMembersProto) -> Result<Self, Self::Error> { | |||
| Ok(Self { | |||
| member_one_inbox_id: value.dm_member_one.unwrap().inbox_id.clone(), | |||
| member_two_inbox_id: value.dm_member_two.unwrap().inbox_id.clone(), | |||
There was a problem hiding this comment.
These unwraps were just on the mls_dms feature branch already. Just cleaning up the linter in this PR. cc @cameronvoell
* Adds functions for creating a DM group (#901) * update bindings cargo locks * Added dm group functionality * dm members can update all metadata * fix tests * fix indentation * fix test imports * gen protos back to main --------- Co-authored-by: cameronvoell <[email protected]> * Private Preferences DB (#946) * create the database migration for the private preference work * update the table to be focused on consent * first pass at database storage structure * update the get method for consent records * fix up the set method * add a test * fix up the test * fix up the clippy error with consent record * fix up the clippy error with consent record * fix up all clippy issues * cargo fmt * Validate dm group metadata + permissions from welcome (#1075) * validate dm group before creating from welcome * lint fix * lint fix --------- Co-authored-by: cameronvoell <[email protected]> * fixes after merge * DM updates - default to not displaying dm groups (#1046) * bindings create_dm function * find groups by default does not include dm groups * fmt fix * dont execute callbacks when dm group welcomes are streamed * Update bindings_ffi/src/mls.rs Co-authored-by: Andrew Plaza <[email protected]> * fixed bad merge * filter dms in stream_conversations * surface include_dm_groups in bindings list function more clearly --------- Co-authored-by: cameronvoell <[email protected]> Co-authored-by: Andrew Plaza <[email protected]> * fix merge conflicts * cargo clippy * Remove tracing from test * Fix test * try and fix the tests * fix up the test --------- Co-authored-by: cameronvoell <[email protected]> Co-authored-by: Naomi Plasterer <[email protected]> Co-authored-by: Andrew Plaza <[email protected]> Co-authored-by: Ry Racherbaumer <[email protected]>
Part of #801
Adds a new table for personal preference records in the local db