Nelze vybrat více než 25 témat Téma musí začínat písmenem nebo číslem, může obsahovat pomlčky („-“) a může být dlouhé až 35 znaků.

__init__.py 6.0 KiB

Resolve and share `state_groups` for all historical events in batch (MSC2716) (#10975) Resolve and share `state_groups` for all historical events in batch. This also helps for showing the appropriate avatar/displayname in Element and will work whenever `/messages` has one of the historical messages as the first message in the batch. This does have the flaw where if you just insert a single historical event somewhere, it probably won't resolve the state correctly from `/messages` or `/context` since it will grab a non historical event above or below with resolved state which never included the historical state back then. For the same reasions, this also does not work in Element between the transition from actual messages to historical messages. In the Gitter case, this isn't really a problem since all of the historical messages are in one big lump at the beginning of the room. For a future iteration, might be good to look at `/messages` and `/context` to additionally add the `state` for any historical messages in that batch. --- How are the `state_groups` shared? To illustrate the `state_group` sharing, see this example: **Before** (new `state_group` for every event 😬, very inefficient): ``` # Tests from https://github.com/matrix-org/complement/pull/206 $ COMPLEMENT_ALWAYS_PRINT_SERVER_LOGS=1 COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh TestBackfillingHistory/parallel/should_resolve_member_state_events_for_historical_events create_new_client_event m.room.member event=$_JXfwUDIWS6xKGG4SmZXjSFrizhARM7QblhATVWWUcA state_group=None create_new_client_event org.matrix.msc2716.insertion event=$1ZBfmBKEjg94d-vGYymKrVYeghwBOuGJ3wubU1-I9y0 state_group=9 create_new_client_event org.matrix.msc2716.insertion event=$Mq2JvRetTyclPuozRI682SAjYp3GqRuPc8_cH5-ezPY state_group=10 create_new_client_event m.room.message event=$MfmY4rBQkxrIp8jVwVMTJ4PKnxSigpG9E2cn7S0AtTo state_group=11 create_new_client_event m.room.message event=$uYOv6V8wiF7xHwOMt-60d1AoOIbqLgrDLz6ZIQDdWUI state_group=12 create_new_client_event m.room.message event=$PAbkJRMxb0bX4A6av463faiAhxkE3FEObM1xB4D0UG4 state_group=13 create_new_client_event org.matrix.msc2716.batch event=$Oy_S7AWN7rJQe_MYwGPEy6RtbYklrI-tAhmfiLrCaKI state_group=14 ``` **After** (all events in batch sharing `state_group=10`) (the base insertion event has `state_group=8` which matches the `prev_event` we're inserting next to): ``` # Tests from https://github.com/matrix-org/complement/pull/206 $ COMPLEMENT_ALWAYS_PRINT_SERVER_LOGS=1 COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh TestBackfillingHistory/parallel/should_resolve_member_state_events_for_historical_events create_new_client_event m.room.member event=$PWomJ8PwENYEYuVNoG30gqtybuQQSZ55eldBUSs0i0U state_group=None create_new_client_event org.matrix.msc2716.insertion event=$e_mCU7Eah9ABF6nQU7lu4E1RxIWccNF05AKaTT5m3lw state_group=9 create_new_client_event org.matrix.msc2716.insertion event=$ui7A3_GdXIcJq0C8GpyrF8X7B3DTjMd_WGCjogax7xU state_group=10 create_new_client_event m.room.message event=$EnTIM5rEGVezQJiYl62uFBl6kJ7B-sMxWqe2D_4FX1I state_group=10 create_new_client_event m.room.message event=$LGx5jGONnBPuNhAuZqHeEoXChd9ryVkuTZatGisOPjk state_group=10 create_new_client_event m.room.message event=$wW0zwoN50lbLu1KoKbybVMxLbKUj7GV_olozIc5i3M0 state_group=10 create_new_client_event org.matrix.msc2716.batch event=$5ZB6dtzqFBCEuMRgpkU201Qhx3WtXZGTz_YgldL6JrQ state_group=10 ```
před 2 roky
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139
  1. # Copyright 2021 The Matrix.org Foundation C.I.C.
  2. #
  3. # Licensed under the Apache License, Version 2.0 (the "License");
  4. # you may not use this file except in compliance with the License.
  5. # You may obtain a copy of the License at
  6. #
  7. # http://www.apache.org/licenses/LICENSE-2.0
  8. #
  9. # Unless required by applicable law or agreed to in writing, software
  10. # distributed under the License is distributed on an "AS IS" BASIS,
  11. # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  12. # See the License for the specific language governing permissions and
  13. # limitations under the License.
  14. SCHEMA_VERSION = 83 # remember to update the list below when updating
  15. """Represents the expectations made by the codebase about the database schema
  16. This should be incremented whenever the codebase changes its requirements on the
  17. shape of the database schema (even if those requirements are backwards-compatible with
  18. older versions of Synapse).
  19. See https://matrix-org.github.io/synapse/develop/development/database_schema.html
  20. for more information on how this works.
  21. Changes in SCHEMA_VERSION = 61:
  22. - The `user_stats_historical` and `room_stats_historical` tables are not written and
  23. are not read (previously, they were written but not read).
  24. - MSC2716: Add `insertion_events` and `insertion_event_edges` tables to keep track
  25. of insertion events in order to navigate historical chunks of messages.
  26. - MSC2716: Add `chunk_events` table to track how the chunk is labeled and
  27. determines which insertion event it points to.
  28. Changes in SCHEMA_VERSION = 62:
  29. - MSC2716: Add `insertion_event_extremities` table that keeps track of which
  30. insertion events need to be backfilled.
  31. Changes in SCHEMA_VERSION = 63:
  32. - The `public_room_list_stream` table is not written nor read to
  33. (previously, it was written and read to, but not for any significant purpose).
  34. https://github.com/matrix-org/synapse/pull/10565
  35. Changes in SCHEMA_VERSION = 64:
  36. - MSC2716: Rename related tables and columns from "chunks" to "batches".
  37. Changes in SCHEMA_VERSION = 65:
  38. - MSC2716: Remove unique event_id constraint from insertion_event_edges
  39. because an insertion event can have multiple edges.
  40. - Remove unused tables `user_stats_historical` and `room_stats_historical`.
  41. Changes in SCHEMA_VERSION = 66:
  42. - Queries on state_key columns are now disambiguated (ie, the codebase can handle
  43. the `events` table having a `state_key` column).
  44. Changes in SCHEMA_VERSION = 67:
  45. - state_events.prev_state is no longer written to.
  46. Changes in SCHEMA_VERSION = 68:
  47. - event_reference_hashes is no longer read.
  48. - `events` has `state_key` and `rejection_reason` columns, which are populated for
  49. new events.
  50. Changes in SCHEMA_VERSION = 69:
  51. - We now write to `device_lists_changes_in_room` table.
  52. - We now use a PostgreSQL sequence to generate future txn_ids for
  53. `application_services_txns`. `application_services_state.last_txn` is no longer
  54. updated.
  55. Changes in SCHEMA_VERSION = 70:
  56. - event_reference_hashes is no longer written to.
  57. Changes in SCHEMA_VERSION = 71:
  58. - event_edges.room_id is no longer read from.
  59. - Tables related to groups are no longer accessed.
  60. Changes in SCHEMA_VERSION = 72:
  61. - event_edges.(room_id, is_state) are no longer written to.
  62. - Tables related to groups are dropped.
  63. - Unused column application_services_state.last_txn is dropped
  64. - Cache invalidation stream id sequence now begins at 2 to match code expectation.
  65. Changes in SCHEMA_VERSION = 73:
  66. - thread_id column is added to event_push_actions, event_push_actions_staging
  67. event_push_summary, receipts_linearized, and receipts_graph.
  68. - Add table `event_failed_pull_attempts` to keep track when we fail to pull
  69. events over federation.
  70. - Add indexes to various tables (`event_failed_pull_attempts`, `insertion_events`,
  71. `batch_events`) to make it easy to delete all associated rows when purging a room.
  72. - `inserted_ts` column is added to `event_push_actions_staging` table.
  73. Changes in SCHEMA_VERSION = 74:
  74. - A query on `event_stream_ordering` column has now been disambiguated (i.e. the
  75. codebase can handle the `current_state_events`, `local_current_memberships` and
  76. `room_memberships` tables having an `event_stream_ordering` column).
  77. Changes in SCHEMA_VERSION = 75:
  78. - The `event_stream_ordering` column in membership tables (`current_state_events`,
  79. `local_current_membership` & `room_memberships`) is now being populated for new
  80. rows. When the background job to populate historical rows lands this will
  81. become the compat schema version.
  82. Changes in SCHEMA_VERSION = 76:
  83. - Adds a full_user_id column to tables profiles and user_filters.
  84. Changes in SCHEMA_VERSION = 77
  85. - (Postgres) Add NOT VALID CHECK (full_user_id IS NOT NULL) to tables profiles and user_filters
  86. Changes in SCHEMA_VERSION = 78
  87. - Validate check (full_user_id IS NOT NULL) on tables profiles and user_filters
  88. Changes in SCHEMA_VERSION = 79
  89. - Add tables to handle in DB read-write locks.
  90. - Add some mitigations for a painful race between foreground and background updates, cf
  91. https://github.com/matrix-org/synapse/issues/15677.
  92. Changes in SCHEMA_VERSION = 80
  93. - The event_txn_id_device_id is always written to for new events.
  94. - Add tables for the task scheduler.
  95. Changes in SCHEMA_VERSION = 81
  96. - The event_txn_id is no longer written to for new events.
  97. Changes in SCHEMA_VERSION = 82
  98. - The insertion_events, insertion_event_extremities, insertion_event_edges, and
  99. batch_events tables are no longer purged in preparation for their removal.
  100. Changes in SCHEMA_VERSION = 83
  101. - The event_txn_id is no longer used.
  102. """
  103. SCHEMA_COMPAT_VERSION = (
  104. # The `event_txn_id_device_id` must be written to for new events.
  105. 80
  106. )
  107. """Limit on how far the synapse codebase can be rolled back without breaking db compat
  108. This value is stored in the database, and checked on startup. If the value in the
  109. database is greater than SCHEMA_VERSION, then Synapse will refuse to start.
  110. """