Page MenuHomePhabricator

[keyserver] Fix existing memberships.last_message in migration
ClosedPublic

Authored by michal on Oct 26 2023, 6:07 AM.
Tags
None
Referenced Files
F2162792: D9605.id32485.diff
Mon, Jul 1, 5:26 PM
F2159054: D9605.diff
Mon, Jul 1, 6:04 AM
Unknown Object (File)
Sun, Jun 30, 10:15 PM
Unknown Object (File)
Sat, Jun 29, 10:31 PM
Unknown Object (File)
Thu, Jun 13, 10:07 AM
Unknown Object (File)
Wed, Jun 12, 4:27 PM
Unknown Object (File)
May 25 2024, 3:05 PM
Unknown Object (File)
May 6 2024, 6:12 AM
Subscribers

Details

Summary

ENG-4101
Depends on D9598

In the previous diff we start correctly setting the memmberships.last_message value for new users. But we still need to update the existing users. This diff adds a new migration that migrates the genesis rows for all users. The query is based on the query from the previous diff but:

  • it doesn't update the last_read_message (we don't need to change it, as it should be correct)
  • it has additional constraints on the main query and the subqueries .thread = 1, so it only searches genesis messages and makes the query faster

Because of these changes and because this is just a migration I don't think it's worth abstracing this query from thread-permission-updaters so I just copied the necessary parts.

Test Plan

Run the migration, check if the last_message was correctly updated.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

(There are no reviewers specified)

Thanks for noticing that, not sure how I missed it

I ran this query in my local environment, which includes a copy of my keyserver's production database from last month. It matched 904 rows and updated 40 rows. It only took 0.122s to complete!

keyserver/src/database/migration-config.js
595 ↗(On Diff #32426)

We should use genesis.id instead of hardcoding 1

This revision is now accepted and ready to land.Oct 27 2023, 1:24 PM