Last modified: 2013-08-22 14:33:10 UTC
Currently there are some problems at wmf servers. That's why my bot is getting a http connection timeout sometimes. This causes my bot to resend the same request mutiple times (action=wbeditentity). http://wikidata.org/w/index.php?title=Q1885918&action=history (three MerlIwBot edits) On the first request sitelink, label and aliases are added. On the second and third request only the aliases where added which already exist because of the first edit. I though this can never happen because my bot always adds baserevid the the request string and the value was wrong after the first internal successful request. So there are two bugs. This one is about the one that aliases are accepted although baserevid is not identical to the last version. That the same alias can be added multiple times in general may be another bug.
Today this happened again: http://wikidata.org/w/index.php?title=Q1756877&diff=next&oldid=6422243
Merlissimo says: there are already 31000 items having duplicate aliases
This is a failure is really in his bot, not in the baserevid. What happens is that he tries to add a set of data values that contains sitelinks, labels, descriptions and aliases. This does a partial save and he gets a failure after the save completes. As he says he adds information during the save operation. After the failure he resends the same request, without doing a reload. During second and third save attempt only the aliases are stored. The reason is that he adds to the existing set. The add operation is unconditional and will not check for unique values, it just adds the new values and the bot says it should do so. In my opinion the correct behavior for the bot would be to reload and inspect the data returned when something like this happen. If we change the behavior to a conditional add, and only accept unique values, then duplicates should be removed before a successful save can be completed. Handling some violating entries while new violations can't be added is counterituitive and should be avoided. An option could be to remove non-unique entries silently, both on save and on load, but I'm not sure we can do that without loosing some error messages that otherwise should be returned. For that to work it would mean to remove all non-unique entries in EntityView, ApiGetEntities, ApiSetAliases and ApiEditEntity. I don't think we should change Entity to handle this error condition, that one should not have the responsibility to clean up user data.
But why is the edit saved if baserevid is wrong? You changed the topic which was originally "wbeditentity ignores baserevid". If it is allowed to add the same alias multiple times it is not an add condition problem. And if this is not wanted it is another bug as i wrote. If on action=edit basetimestamp or starttimestamp are wrong i am getting an edit conflict. I though baserevid on action=wbeditentity would also cause an edit conflict if the value is not the id of the last version. The same situation can also happen if i read the item first. Then an another users adds aliases. Later i can could add the same alias because i don't know about the edit in between.
This should no longer happen as WikibaseDataModel now ensures the array of aliases is unique before saving and will remove any duplicate values.
