Skip to content

refactor: use unified connection [WPB-23775]#2303

Open
coriolinus wants to merge 18 commits into
mainfrom
prgn/refactor/23775-use-unified-connection
Open

refactor: use unified connection [WPB-23775]#2303
coriolinus wants to merge 18 commits into
mainfrom
prgn/refactor/23775-use-unified-connection

Conversation

@coriolinus

Copy link
Copy Markdown
Contributor

What's new in this PR

Partially implements 23775. This accomplishes most of that PR, except for two more steps:

  • Rename all Unified* entity trait family traits to rm the Unified prefix
  • Fix all the errors which fall out of this API changes in CC.

One issue I see right away: this new Database wraps a connection directly, where the old one wrapped a Mutex<Option<Connection>>. This means we can no longer use the Database::close method, because it consumes self and consumers all always have an Arc<Database>.

Whoever picks this up will need to either adjust that and all the access patterns, or determine that we can omit close methods entirely now.


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.

coriolinus added 18 commits July 2, 2026 15:51
We are now deprecating the old connection module in favor of the
unified connection, and removing platform-specific code from the
entity implementations.

Unfortunately, we need to retain sufficient wasm code that we can
still run enough of a migration to upgrade into the new unified
entity database, and that means that we've got a whole rump of otherwise-
useless code sitting in the legacy module. Can't be helped, unfortunately.
We're deprecating those in favor of the new `UnifiedEntity` traits
and will eventually update the names to remove the `Unified*` prefix.

The old traits still exist and are implemented in the
`idb_migration::legacy` module.
We only need the new stuff now. Old implementations can live in
the legacy module.
Just keeping things in parity with the old `Database` impl.
- rm now-obsolete trait implementations
- move certain implementations out of the platform module
- in general make the entities implement what they need inline
`Database` needs to be able to manage the `KeystoreTransaction`
lifecycle, so we organize these methods centrally here.
At this point I can't even explain why that was necessary, but it
was necessary to make everything work, so here it is.
Previously we'd been using the old `Database` and `Entity` trait
family pervasively. We need to switch to the new stuff, so here we do.
We'd previously had a pointless trait which was implemented on
the database and on nothing else, even for testing. That wasn't
helping anything, so we got rid of it.

Also updates the proteus-specific methods to use the new entity traits.
We'd previously had a pointless trait which was implemented on
the database and on nothing else, even for testing. That wasn't
helping anything, so we got rid of it.

Also updates the mls-specific methods to use the new entity traits.
The code previously under test is now effectively unchanging; no new development
will touch it. And it's now buried deep in the legacy migration module;
it's not exposed publicly anymore.

Therefore, we get rid of this test, because there's no longer a compelling reason
why it should still exist.
This is mainly a convenience: it's not strictly necessary, but
as consumers all accept an `Arc<Database>` anyway, there's no
point making users construct the `Arc` themselves.
@coriolinus coriolinus requested a review from a team July 2, 2026 14:52
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