daniel added a comment.
Quick fix for the error: just remove the check that triggers the error. Could be converted to a warning, or just a debug message. However, this doesn't solve the conceptual problem of breaking all existing references to the old entity ID, internal and external. @Mholloway said: > What should happen here? Should the entity always retain its original ID even after a page move, or should the entity ID always reflect the current page ID of the page with which it's associated? Ideally, undeletion would not change the page ID. Core already tries to retain the original page ID, but it's not always possible. Fixing this is a complicated project, see T193690: RFC: How should we fix the undeletion system? <https://phabricator.wikimedia.org/T193690>. I wonder though why the page ID wasn't restored in this case - I don't really see a reason for that. From the Wikibase model perspective, entity IDs should never change. So the original ID needs to be retained. The question is how that could be made to work... > The assumption that the entity ID will always reflect the (current) page ID seems pretty well baked in at this point, so maybe the entity IDs should just be updated as discrepancies are found. On the other hand, that risks masking any deeper issues that arise. Indeed - From the perspective of EntityTitleLookup (as far as I remember it from a couple of years ago), the mapping of an ID to a page Title needs to be programmatic - for Items, the ID is the title text, and for MediaInfo, the title is the page ID. If the page ID changes, the page can no longer be found given the MediaInfo ID. To make this work, the mapping from MediaInfo ID to Title would have to be maintained in the database. What could be done is fixing the self-reference in the EntityContent at load time. This way, the JSON emitted from Special:EntityData and in dumps would contain the new ID, even though the database doesn't. > Better, if we want to preserve the correspondence between mediainfo IDs and page IDs, would be to hook into ArticleUndelete and update the mediainfo ID if the page ID has changed. (Despite what its name might suggest, that hook isn't restricted to NS_MAIN, but appears to fire when any page from any namespace is restored.) That would mean changing the content of the revision, which changes the hash of the revision. While this is not impossible, MediaWiki core doesn't offer any way to update a revision's content after it was saved, and doing so may break expectations. @Lydia said: > Not my decision to make but those are presumably stable identifiers that reusers of the data can rely on just like Wikidata Q-IDs for Items. In this case you'll probably want to make the data available under both IDs. Wikidata does this with redirects on Items and Lexemes. Keeping a redirect from the old ID to the new ID (plus rewriting the internal slef-reference upon load) is probably the cleanest solution. It however requires that mapping to be maintained somewhere somehow. Some kind of wikibase-internal alias mechanism, stored as a table in the database. This fits with the model, the problem is mainly maintaining the mapping. Perhaps the ArticleUndelete hook could be used for that. Perhaps also the code that currently does that check and throws the error could instead check if the mapping is already recorded, if not store it in the DB. And of course fix the ID contained in the Entity object itself. Note that keeping a table with aliases is similar to but not the same as maintaining the mapping from MediaInfoId to page ID in the database. The alias table would be much smaller. And would only be consulted when the "normal" lookup fails. On the other hand, it introduces a special case, somewhat increasing code complexity. TASK DETAIL https://phabricator.wikimedia.org/T231276 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Pablo-WMDE, Urbanecm, Zoranzoki21, Yann, WMDE-leszek, Lydia_Pintscher, Cparle, Mholloway, Addshore, hashar, ArielGlenn, Lucas_Werkmeister_WMDE, Liuxinyu970226, Aklapper, zeljkofilipin, darthmon_wmde, alaa_wmde, DannyS712, Nandana, Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Ricordisamoa, Jdforrester-WMF, Mbch331, Jay8g, Krenair
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
