Page MenuHomePhabricator

Setup CommunityRequests tables for querying via a virtual domain
Closed, ResolvedPublic8 Estimated Story Points

Description

Background

See T403559: Add CommunityRequests tables to production for context.

CommunityRequests tables don't need to be on the main DB clusters, so in order to reduce the load on those clusters we should host the new tables on x1 instead

To query tables on x1 we need to set up a virtual domain, and use a separate db connection that connects via that domain.

r1003510 is an example patch connecting to x1 via a virtual domain, and see here for where the domain is set up in config

Acceptance criteria
  • Register a virtual domain in extension.json
  • Update SchemaHooks to use DatabaseUpdater::addExtensionUpdateOnVirtualDomain() etc.
  • Remove any JOINs on the page table and do those as separate queries
  • CommunityRequests tables should be queried using a connection to the virtual domain
  • Queries to Core tables should be made via a different regular MW db connection

In an effort to keep to keep patches small(ish), the work should be split between these subtasks.

Event Timeline

• KSiebert set the point value for this task to 8.Sep 9 2025, 7:35 PM
MusikAnimal changed the task status from Open to In Progress.Sep 10 2025, 5:53 AM
MusikAnimal claimed this task.
Cparle renamed this task from Migrate CommunityRequests tables to virtual domain mapping to Setup CommunityRequests tables for querying via a virtual domain.Sep 10 2025, 8:16 AM
Cparle updated the task description. (Show Details)

This is not because CommunityRequests will be used on multiple wikis (which x1 is typically used for), rather x1 just has a lot more breathing room so it will be a good fit for us.

Just to note that this is a common misconception. There is a wikishared database on x1 for shared/central tables and features but each wiki has its own database too and many features while not being central, use x1 instead of core. Being central is a nice addition but the main purpose of x1 is to offload core sections not centrality.

Just to note that this is a common misconception. There is a wikishared database on x1 for shared/central tables and features but each wiki has its own database too and many features while not being central, use x1 instead of core. Being central is a nice addition but the main purpose of x1 is to offload core sections not centrality.

Thanks for clarifying! I had thought that given what you told us in our 1:1, but the docs say x1 is for "databases that are "global" or "cross-wiki" in nature". I don't know if deserves any rewording, just pointing it out. (I know it's a wiki and I can edit it too, but I clearly am not qualified to try to explain x1, hehe)

• Samwilson changed the task status from In Progress to Open.Sep 10 2025, 11:46 PM
• HMonroy changed the task status from Open to Stalled.Sep 11 2025, 12:44 AM
• HMonroy subscribed.

There's a couple of subtasks that will resolve this tasks.

MusikAnimal claimed this task.

Looks like we're all done here! QA is just "make sure nothing broke" and that can be a collective effort.