Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.

Commit 35e9d6a

Browse files
Emphasize the right reasons to use (room_id, event_id) in a schema (#13915)
* Emphasize the right reasons to use (room_id, event_id) Follow-up to: - #13701 - #13771
1 parent f5aaa55 commit 35e9d6a

File tree

2 files changed

+17
-15
lines changed

2 files changed

+17
-15
lines changed

changelog.d/13915.doc

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Emphasize the right reasons when to use `(room_id, event_id)` in a database schema.

docs/development/database_schema.md

+16-15
Original file line numberDiff line numberDiff line change
@@ -195,23 +195,24 @@ There are three separate aspects to this:
195195

196196
## `event_id` global uniqueness
197197

198-
In room versions `1` and `2` it's possible to end up with two events with the
199-
same `event_id` (in the same or different rooms). After room version `3`, that
200-
can only happen with a hash collision, which we basically hope will never
201-
happen.
202-
203-
There are several places in Synapse and even Matrix APIs like [`GET
198+
`event_id`'s can be considered globally unique although there has been a lot of
199+
debate on this topic in places like
200+
[MSC2779](https://github.com/matrix-org/matrix-spec-proposals/issues/2779) and
201+
[MSC2848](https://github.com/matrix-org/matrix-spec-proposals/pull/2848) which
202+
has no resolution yet (as of 2022-09-01). There are several places in Synapse
203+
and even in the Matrix APIs like [`GET
204204
/_matrix/federation/v1/event/{eventId}`](https://spec.matrix.org/v1.1/server-server-api/#get_matrixfederationv1eventeventid)
205205
where we assume that event IDs are globally unique.
206206

207-
But hash collisions are still possible, and by treating event IDs as room
208-
scoped, we can reduce the possibility of a hash collision. When scoping
209-
`event_id` in the database schema, it should be also accompanied by `room_id`
210-
(`PRIMARY KEY (room_id, event_id)`) and lookups should be done through the pair
211-
`(room_id, event_id)`.
207+
When scoping `event_id` in a database schema, it is often nice to accompany it
208+
with `room_id` (`PRIMARY KEY (room_id, event_id)` and a `FOREIGN KEY(room_id)
209+
REFERENCES rooms(room_id)`) which makes flexible lookups easy. For example it
210+
makes it very easy to find and clean up everything in a room when it needs to be
211+
purged (no need to use sub-`select` query or join from the `events` table).
212+
213+
A note on collisions: In room versions `1` and `2` it's possible to end up with
214+
two events with the same `event_id` (in the same or different rooms). After room
215+
version `3`, that can only happen with a hash collision, which we basically hope
216+
will never happen (SHA256 has a massive big key space).
212217

213-
There has been a lot of debate on this in places like
214-
https://github.com/matrix-org/matrix-spec-proposals/issues/2779 and
215-
[MSC2848](https://github.com/matrix-org/matrix-spec-proposals/pull/2848) which
216-
has no resolution yet (as of 2022-09-01).
217218

0 commit comments

Comments
 (0)