resolver: allow to force update specific claims

[jum-s]

Replace entity claims with entry claims of properties declared in the forceUpdateProps parameter (renaming welcome)

Usecase: an editor catalogue, representing the most canonical data is passed through the resolver. But some formating of this catalogue may be less precise than existing inv entities claims.

forceUpdateProps allow to update only the publication date for example, date format being less subjected to interpretation than a title.

• early parameter validation: against properties values constraints list
• perform an update, aka only if claim already exists (allowing to not check entity type before update)
• rely on not updating wikidata items policy already implemented in
  update_resolved_entry

[maxlath]

Suggested change

	getEntity(prefix, entityId)
	return getEntity(prefix, entityId)

I would be in favour of returning those promises (this one and the following), so that we wait for it to resolve before moving to the next operations, as that makes everything simpler: you can build on the assumption that a certain thing was done once the function returned value was resolved, while if you don't return the promise, you don't wait for it, thus uncertainty unfolds. It also makes error handling easier: when something somewhere in the resolve fails, we can stop the resolve for that entity, and handle the error at the appropriate level.

Worse, since NodeJS v15, if any error happens in those non-returned promises, it will be considered an unhandled promise and will make the process exit, so the only viable alternative to not returning promises would be to set a .catch(_.Error('foo') on all of them

[maxlath]

Suggested change

	const updateClaims = (seedClaims, userId, batchId, forceUpdateProps) => entity => {
	addMissinClaims(seedClaims, userId, batchId, entity)
	const updateClaims = (seedClaims, userId, batchId, forceUpdateProps) => async entity => {
	await addMissingClaims(seedClaims, userId, batchId, entity)

same as above, wait for promises

[maxlath]

same: return promises

[maxlath]

Suggested change

	.then(Wait(100))
	await wait(100)

[maxlath]

by calling entities_.putUpdate directly, it skips validateClaims (validateAndFormatClaims on current master branch): that's a problem, as mistakes happens, and this validation can be precious to avoid a wide range of errors (ex: setting an entity of type work in place of a publisher or setting an edition ISBN to an ISBN already used by another edition)

[maxlath]

Adding only the missing values was the low hanging fruit, trying to update existing data en mass is much more challenging: I would be in favour of postponing this PR to when we can refactor it with the fruits of #400, particularly to benefit from the formatting and validation. We might also benefit from some cleanup steps: to take your example, if a wd entity replaces an inv entity as publisher, there could be a check on the inv entity to see what action should be taken. Maybe creating a task? That could allow the person working on that task to import any existing data from that inv entity missing on the wd entity

[jum-s]

yep, replacing uris looks challenging indeed. But some "hardcoded" values (as non uris values) could be automatically updated, this is exactly what #507 is trying to do.
It can be discussed in a new issue, but if "a wd entity replaces an inv entity as publisher" what could be done is to update the claim but also to try to "garbage collect" "orphan" publishers by redirecting them to the wd entity.
I dont think there is any reason to refuse en mass claim updates that can be updated individually, as long as tools to reverse it exist (batch_id).