daniel created this task.
daniel triaged this task as "Normal" priority.
daniel added projects: Wikidata, Structured-Data-Commons, Multi-Content-Revisions, User-Addshore.


The slots table currently contains the slot_inherited field, which is a flag that indicates whether a slot was inherited from a previous revision, rather than having been touched in the current revision. However, when revisions get moved to the archive table ("hard" revision deletion), there may not be a good way to find the revision that originated the slot's content - which means it's effectively impossible to determine the content's author. This is aggravated by the fact that the rev_parent relation is updated when revisions get restored.

To address this problem, slot_inherited should be replaced by slot_origin, which would record the ID of the revision that originated the slot's content. This would allow the content's author to be determined reliably. It would even allow us to warn users when a diff skips a deleted edit, and thus may mis-represent authorship.


  • Since the slots table was only introduced after 1.30 was branched, and 1.31 is not branched yet, no migration is needed for installations using a stable release.
  • Since current master of MediaWiki does not actually use the slots table, even though it creates it on install or upgrade, no data migration/population is needed for live production systems or even development environments.
  • Fresh installs can simply create slot_origin instead of slot_inherited
  • If the slots table exists and has the slots_origin field, a database patch needs to be executed that drops slot_inherited, and adds the slot_origin field.



To: Addshore, daniel
Cc: Tgr, Anomie, Aklapper, gerritbot, Addshore, tstarling, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331
Wikidata-bugs mailing list

Reply via email to