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)
Tue, Dec 31, 7:20 AM
Unknown Object (File)
Tue, Dec 31, 7:20 AM
Unknown Object (File)
Tue, Dec 31, 7:20 AM
Unknown Object (File)
Tue, Dec 31, 7:20 AM
Unknown Object (File)
Tue, Dec 31, 7:11 AM
Unknown Object (File)
Sun, Dec 29, 3:05 PM
Unknown Object (File)
Mon, Dec 9, 1:39 PM
Unknown Object (File)
Dec 1 2024, 7:24 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
Branch
michal/last-message-v2
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

We should use genesis.id instead of hardcoding 1

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