| daniel added a comment. |
@jcrespo wrote:
No, I was asking to keep recentchanges as it was before, with the previous load/meaning and implement "new features" on separate tables, or on separate servers.
Well... it's not really a new feature. The recentchanges table is the standard mechanism for surfacing changes to users via the recentchanges and watchlist UIs and APIs. IF we don't use the recentchanges tbale for this, we have to implement "on the fly join" logic in several places, and make it work efficiently with filtering and paging. This would be a major overhaul, it's not doable on short notice.
Also, since you said that you "think the materialization is a wrong approach", we should probably consider getting rid of recentchanges altogether in that case.
This can't be done short term, and probably not even mid term. This transition would probably take a couple of years (MCR scale). We can't live without notifications for so long, that would probably kill the SDC project. So we need an alternative solution that is feasible as a mid term solution. Do you have an idea?
both start from the idea of implementing table inheritance "wrongly".
How is that? In my mind, "table inheritance" refers to the attempt to store entities that share only some properties in a relational database - correctly using references, or wrongly using nullable fields. But how is this the case here? Recentchanges rows that are triggered by wikidata do not have different properties from regular entries. The only difference is in how they are triggered.
Cc: Jdforrester-WMF, brion, Mattflaschen-WMF, Strainu, TerraCodes, Jay8g, Liuxinyu970226, jcrespo, Bawolff, Aklapper, hoo, daniel, Ladsgroup, Lydia_Pintscher, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
