This is especially obvious when saving mappings via Cocoda. You save a mapping which is confirmed, but the subsequent mapping request will not yet return the mapping we just saved. For the user, it will be unclear whether the mapping was actually saved. Only after the next refresh of the mappings will the change be shown.
Ideally, a mapping request should return the new/changed mapping immediately after saving the mapping. As this is likely a limitation of the Wikidata SPARQL endpoint, we might have to add a kind of mapping cache which stores recently saved mappings and potentially includes it in a mapping request. Of course this can get complicated if the request has pagination and it is not clean where in the list the mapping should be inserted. So if we solve it this way, we might need to limit it to specific mapping requests (where either from or to are given, for example).
This is especially obvious when saving mappings via Cocoda. You save a mapping which is confirmed, but the subsequent mapping request will not yet return the mapping we just saved. For the user, it will be unclear whether the mapping was actually saved. Only after the next refresh of the mappings will the change be shown.
Ideally, a mapping request should return the new/changed mapping immediately after saving the mapping. As this is likely a limitation of the Wikidata SPARQL endpoint, we might have to add a kind of mapping cache which stores recently saved mappings and potentially includes it in a mapping request. Of course this can get complicated if the request has pagination and it is not clean where in the list the mapping should be inserted. So if we solve it this way, we might need to limit it to specific mapping requests (where either
fromortoare given, for example).Any other ideas?