Skip to content

feat: add unified keystore connection [WPB-23773]#1933

Draft
coriolinus wants to merge 17 commits intomainfrom
prgn/feat/23773-unified-keystore-connection
Draft

feat: add unified keystore connection [WPB-23773]#1933
coriolinus wants to merge 17 commits intomainfrom
prgn/feat/23773-unified-keystore-connection

Conversation

@coriolinus
Copy link
Contributor

What's new in this PR

Create a rusqlite connection for the keystore that's usable both in native and wasm compilation environments.


PR Submission Checklist for internal contributors
  • The PR Title
    • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
    • contains a reference JIRA issue number like SQPIT-764
    • answers the question: If merged, this PR will: ... ³
  1. https://sparkbox.com/foundry/semantic_commit_messages
  2. https://github.com/wireapp/.github#usage
  3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

This isn't really part of the connection anyway.
This type wraps a bare rusqlite `Connection` when in memory or running
locally, and one with a IDB VFS when on `target_os = "unknown"`.
It also refactors the initialization a bit to minimize code duplication.

The `ConnectionWrapper` and `RusqliteConnection` items aren't really final;
they work for the moment, but I don't love them. Need to put a bit more
thought into how precisely I want this all to work.
…ction

This may not be the optimal placement for these; I want to revisit the
project layout again after we have deleted the old connection code.
For now, they're all in place at least.
We need to have some kind of abstraction in the unified database,
because we want to support operations like "wipe" which involve simply
deleting the database. But there's no particular reason that abstraction
needs to include the actual connection, so we separate that part out.

This turns out to simplify everything.
…atabase

We can't fully support this yet without adjusting certain intefaces in
`KeystoreTransaction`, but we can get it started.
Like it or not, we still need this capability at least on known-os
platforms, so here it is.
This means we don't have to mess with the `FetchFromDatabase` trait
or any writeable entity methods; people can just use the relevant
`UnifiedEntity` traits directly.

We probably want to change this up in the future. This approach means that
I save a lot of work right now messing with traits which are in flux,
but it also means that it's possible to bypass the CC transaction
entirely and just do writes directly to the database. See WPB-24064.

In the meantime, this is worth it just because it means we don't have
to write _any_ entity-specific code on the `Database` for now.
Major changes:

1. everything is sync because sqlite is not async
2. connection, transaction are specified explicitly instead of as associated types
3. eliminated `EntityBase`
These act like the old generic helpers, but tuned for the new unified entity traits.
It's much easier to work on a bunch of individual focused files
than a few massive files containing a ton of entities each.
These files only contain the one entity, so name them appropriately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant