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
Unknown Object (File)
Wed, Nov 20, 10:50 AM
Unknown Object (File)
Sat, Nov 9, 11:41 AM
Unknown Object (File)
Sat, Nov 9, 11:39 AM
Unknown Object (File)
Sat, Nov 9, 10:51 AM
Unknown Object (File)
Sat, Nov 9, 8:29 AM
Unknown Object (File)
Thu, Nov 7, 5:09 PM
Unknown Object (File)
Oct 15 2024, 3:24 PM
Unknown Object (File)
Oct 15 2024, 11:10 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
No Lint Coverage
Unit
No Test Coverage

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