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
F2185232: D9605.diff
Wed, Jul 3, 11:26 PM
F2183463: D9605.id.diff
Wed, Jul 3, 7:55 PM
Unknown Object (File)
Mon, Jul 1, 5:26 PM
Unknown Object (File)
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
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