Page MenuHomePhabricator

Investigate why (and fix) JSON representation of entity on Special:EntityData drops the repository name prefix from foreign entity used in the statement
Closed, InvalidPublic

Description

Noticed while testing federation code. Test setup was: Repo 1 ("main") provides properties, Repo 2 provides items.
When using properties from "main" on repo 2, statement data for the item is missing the repository prefix, see excerpt from the "claims" part of item data:

{"P2":[{"mainsnak":{"snaktype":"value","property":"P2","datavalue":{"value":{"entity-type":"item","numeric-id":2,"id":"Q2"}

Repository name is correctly stored in the database.

First suspect is that while StatementModificationHelper::getEntityIdFromString is parsing the serialized ID, the parser for some reason drops the prefix (maybe maps it to an empty prefix).
This behaviour must be investigated. If fixing the problem turns out to be complex, please file a separate ticket outlining the solution.

Patches for review:

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
DuplicateNone
OpenFeatureNone
OpenFeatureNone
DuplicateNone
ResolvedNone
ResolvedNone
ResolvedNone
OpenNone
OpenNone
StalledNone
ResolvedLydia_Pintscher
ResolvedLydia_Pintscher
ResolvedLydia_Pintscher
ResolvedLydia_Pintscher
Invaliddaniel
Resolvedthiemowmde

Event Timeline

WMDE-leszek renamed this task from Investigate why (and fix) Api\SetClaim drops the repostiory name prefix from foreign entity used in the statement to Investigate why (and fix) JSON representation of entity on Special:EntityData drops the repostiory name prefix from foreign entity used in the statement.Feb 7 2017, 2:47 PM
WMDE-leszek updated the task description. (Show Details)

I ran into several issues while trying to investigate this. One of them is related to the fact that we use serialiez/unserialiez to clone statements, and serialization of Snaks and EntityIdValue uses numeric IDs. Patch on github: https://github.com/wmde/WikibaseDataModel/pull/716

Ricordisamoa renamed this task from Investigate why (and fix) JSON representation of entity on Special:EntityData drops the repostiory name prefix from foreign entity used in the statement to Investigate why (and fix) JSON representation of entity on Special:EntityData drops the repository name prefix from foreign entity used in the statement.Feb 9 2017, 10:05 AM
Ricordisamoa updated the task description. (Show Details)
thiemowmde updated the task description. (Show Details)
thiemowmde moved this task from Proposed to Review on the Wikidata-Former-Sprint-Board board.
thiemowmde moved this task from incoming to in progress on the Wikidata board.
thiemowmde subscribed.

Breaking news: this seems to be working on current master (tested locally, 9dcffbca5a4f91915e872cc998039c5c57aabd63) but also on slightly older master (on labs instance, running a99a802cd4621ea5a21bc31d1542a60b5f7d0144.
Now I really need to investigate what was wrong before so it didn't work, as it seems changes in serializers might not be relevant here? (although I believe they're still valid changes).

EDIT: I am very confused. The above comment might not be valid. The local version I am trying out seems to work OK, and I am confused what Labs instance shows me (sometimes it prefixes the output sometimes not). I will further into that.

The problem with missing prefix in the JSON data seems to not be happening any mare with the current master of Wikibase git (using current Data Model 6.3.1).
I was trying to track down if any changes to Wikibase code in last few weeks fixed it but failed to find anything. I tend to think it was some configuration problem, or maybe something was cached on Labs (this is where the issue was originally discovered). I didn't see it happening for few weeks, and cannot reproduce it.

Problem Daniel ran into seems unrelated to the prefix issue, as are in my opinion fixes in the Data Model. That issue might have been somewhat related to Wikibase using wrong serializer for entities: T160426.

As the missing prefix in JSON data issue seems to not be a problem any more, I close this ticket. It should be re-opened if the problems appears again, then we should be able to reproduce it.