Page MenuHomePhabricator

Put lastrevid of linked entities in mw.config.values.wbUsedEntities
Closed, DeclinedPublic

Description

When viewing an entity, wbUsedEntities currently contains JSON (a string, not an actual javascript object) representing an object with all entities and some of their attributes, namely for each :

  • datatype (string)
  • descriptions (localized, as an object)
  • id (string, "P<id>" for a property, "Q<id>" for an item)
  • labels (localized, as an object)
  • type (one of "item", "property")

However, when performing an API call on a "used entity" using the mw.api.edit module, you should also provide the lastrevid for that entity in order to avoid edit conflicts. Gadgets currently don't check for edit conflicts : that is not sane behaviour, but they don't have much of a choice in the matter.

Performing an API call to get the lastrevid would create two problems :

  • you have to perform an API call to get it
  • the lastrevid may have changed since you loaded the page, even though the current page hasn't (because it's been loaded back then)

The current format of wbUsedEntities is as follows :

{"P<id>":{"content":{"type":"property","id":"P<id>","labels":{"en":{"language":"en","value":"P<id> english label"}},"descriptions":[],"datatype":"wikibase-item"},"title":"Property:P<id>"},"Q<id>":{"content":{"type":"item","id":"Q<id>","descriptions":{"en":{"language":"en","value":"Q<id> english description"}},"labels":{"en":{"language":"en","value":"Q<id> english label"}}},"title":"Q<id>"}}

Adding the lastrevid would make wbUsedEntities into :

{"P<id>":{"content":{"type":"property","id":"P<id>","labels":{"en":{"language":"en","value":"P<id> english label"}},"descriptions":[],"datatype":"wikibase-item"},"title":"Property:P<id>", "lastrevid": <numeric lastrevid for P<id>>},"Q<id>":{"content":{"type":"item","id":"Q<id>","descriptions":{"en":{"language":"en","value":"Q<id> english description"}},"labels":{"en":{"language":"en","value":"Q<id> english label"}}},"title":"Q<id>", "lastrevid": <numeric lastrevid for Q<id>>}}

Event Timeline

Alphos raised the priority of this task from to Needs Triage.
Alphos updated the task description. (Show Details)
Alphos subscribed.

I'm currently working on removing wbUsedEntities, see https://gerrit.wikimedia.org/r/#/c/197290/. You would have to do an API request then, anyways. As for the current page, wgCurRevisionId gives you the revid, but I guess you knew that already :)

I did find wgCurRevisionId ;-)

Too bad about wbUsedEntities being dropped, it means we're either :

  • facing race conditions (and potential unnoticed edit conflicts) : the lastrevid of the used entities may have changed since the loading of the current page
  • or not caring (and creating potential unnoticed edit conflicts), which is even worse.

Alternatively, to lessen the probability of race conds (though not as efficiently as providing it straight away), it could be interesting to provide the lastrevid of an entity when performing a wbgetclaims API call on it.

Edit : Or i could use wbgetentities, as an alternative to wbgetclaims. Returned content will likely be very verbose compared to what will be needed (including claims I don't need), but it'll provide the data I need nonetheless…

Can you give me a use-case for editing an entity referenced by the entity you're currently on? I think it makes more sense to provide the lastrevid with wbgetclaims, and I think you definitely should run wbgetclaims before doing wbsetclaims, otherwise you don't really know what you are modifying in the first place.

I'm working on a gadget that will allow you to insert by hand only one side of a relationship, and click for an automated insertion of the other side.
Let me clarifiy with a real world example :

Imagine the two items exist, but their properties aren't set yet.

  1. You set the P131 (is located in) property of https://www.wikidata.org/wiki/Q532352 (La Villette), with qualifiers and references, by hand.
  2. And you have to do it again on the other side, setting P150 (has subdivision) on Q1142326 (Seine) and setting the same qualifiers and references, also by hand.

The gadget I'm creating would make step 2 shorter by having it done on the click of a button placed on the first page you edit. It will only work for one claim per click, for anything too big a batch process (bot or quick-statements) would be more appropriate.
It would also make sure that a similar claim (same property pointing to the same item - the current, "local" item) doesn't already exist on the "remote item" (the one that will be automatically edited) ; if one does exist, it would only add missing qualifiers and references to it ; and it would do nothing in case several similar claims exist (performing an action would be non-trivial).
I'm obviously already making an API call to wbgetclaims in order to perform the prior checks mentionned above ;-)

The list of Wikidata property pairs that are concerned is quite extensive, and the gadget would reduce the amount of redundant actions performed by hand by users :

{
  "P361": "P527",
  "P527": "P361",
  "P301": "P910",
  "P910": "P301",
  "P155": "P156",
  "P156": "P155",
  "P460": "P460",
  "P184": "P185",
  "P185": "P184",
  "P1066": "P802",
  "P802": "P1066",
  "P1344": "P710",
  "P710": "P1344",
  "P22": "P40",
  "P25": "P40",
  "P26": "P26",
  "P451": "P451",
  "P43": "P40",
  "P44": "P40",
  "P355": "P749",
  "P1308": "P39",
  "P1478": "P1536",
  "P1536": "P1478",
  "P1479": "P1537",
  "P1537": "P1479",
  "P747": "P629",
  "P688": "P702",
  "P702", "P688",
  "P828": "P1542",
  "P1542": "P828",
  "P150": "P131",
  "P1383": "P131",
  "P47": "P47",
  "P190": "P190",
  "P398": "P397",
  "P397": "P398"
}

It is not however a plain pair list : properties A and B may both be "inversed" into property C, which forbids "inversing" C automatically. See for instance properties 22, 25, 43, and 44 (parents and step-parents) which all share the same inverse, property 40 (child).

That sounds great :) I think you can and should use wbgetentities. If you set props=claims|info, you only get the claims and meta data, which shouldn't be to expensive.

Way ahead of ya ;-)
Current implementation (JS on test.wikidata) performs the action=wbgetclaims&props=claims|info call at window.onload time on items that are targetted by properties of interest.
Still wrapping my head around widgets and triggered events, planning on implementing them to do things more cleanly, but that's another talk altogether.

Thanks for your input !

Lydia_Pintscher claimed this task.
Lydia_Pintscher subscribed.

Since this seems solved I am going to close the ticket.