Editing API: return revision id on successful edit about wikidata-toolkit HOT 5 CLOSED

@robertvazan I realized that this was actually supported by the previous editing API, that is now deprecated.
Beyond returning the revision id, that editing API also returned the new state of the document after editing, which feels like a useful feature too.

I think it would be useful to bring this feature back in the new API. The way I would go about it is change the EntityUpdate classes so that they do not just hold the base revision id to work from, but also (optionally) the state of the document at that revision id.
I have realized that the Builder classes for EntityUpdate actually let us start from such a document - it just is not stored in the built object so far. So I would store those in the built updates, and then use that in WikibaseDataEditor to reconstruct the state of the edited document by reunifying the JSON returned by the server with the initial state of the document (just like the old API does).

Does that seem sensible to you?

What I actually need here is access to the new revision id (to be able to generate a diff URL for all edits made via WDTK) but it feels sensible to also add the ability to return the full edited document in the same go.

from wikidata-toolkit.

Here's the relevant discussion: #403 (comment)

WDTK currently implements option 1. You seem to be proposing fifth option like this:

1. Do not return updated entity from edit operations.
2. Sacrifice nice edit messages and use wbeditentity for everything.
3. Prohibit blind edits and require base entity document to create XUpdateBuilder objects.
4. Fetch the new document after performing the edit via wbgetentities.
5. If base entity was provided when creating XUpdateBuilder, use it to return updated entity from edit functions, otherwise return null (or rather empty Optional).

I don't remember why an extra network roundtrip might be necessary in case 3 and whether it would also apply to case 5. I guess it might have something to do with either concurrent edits or incomplete responses to edit requests.

I think it is a bit weird for WDTK to fake returning modified entity when the underlying API does not always support it and where it does, the response is sometimes subtly different from fresh fetch. WDTK users can always do it themselves with a single method call that applies the edit to the base revision they have. I have certainly planned this "apply edit locally" API, but I don't think I have implemented it yet. You would probably have to implement it first if you want to return modified entity from edit methods.

This issue is about returning revision ID rather than the whole updated document. I think that was not possible with all Wikibase APIs when I was implementing this, so I omitted the functionality.

from wikidata-toolkit.

Ah, thanks for bringing back this discussion, I also had the feeling we had discussed that earlier.

I think it is a bit weird for WDTK to fake returning modified entity when the underlying API does not always support it and where it does, the response is sometimes subtly different from fresh fetch. WDTK users can always do it themselves with a single method call that applies the edit to the base revision they have. I have certainly planned this "apply edit locally" API, but I don't think I have implemented it yet. You would probably have to implement it first if you want to return modified entity from edit methods.

Yes, I do not want to "apply the edit locally", in the sense that I do not want to re-implement the logic that the Wikibase server is holding. But as far as I can tell the responses of all of the actions we currently support make it really easy to return an updated document state. By relying on those JSON responses I think the risk that we are getting out of sync is really low.

For instance, if you use wbsetaliases to add certain aliases and remove others in a language, the server responds with the final list of all aliases in that language. So you can just take that and insert it in the document in place of all previous aliases to get the new state. No need to worry about the order in which things are added and deleted or manually retrieving the untouched aliases.

This issue is about returning revision ID rather than the whole updated document. I think that was not possible with all Wikibase APIs when I was implementing this, so I omitted the functionality.

From what I can tell, all API actions we use return the new revision id.

The thing is: as a user there is no workaround for this functionality. I can fetch the state of the document immediately after, but I have no guarantee that no other edit was made in the meantime - so perhaps the latest revision id is not the one of the edit I just made. I guess I could retrieve the history of the entity (although WDTK does not support that yet) and try to match the edit I made to find it in the list, but do we agree that it's really messy? Or how else do you suggest I generate a diff URL?

from wikidata-toolkit.

The thing is: as a user there is no workaround for this functionality. I can fetch the state of the document immediately after, but I have no guarantee that no other edit was made in the meantime - so perhaps the latest revision id is not the one of the edit I just made. I guess I could retrieve the history of the entity (although WDTK does not support that yet) and try to match the edit I made to find it in the list, but do we agree that it's really messy? Or how else do you suggest I generate a diff URL?

Indeed, if you need diff URL, there's no way around parsing the new revision ID out of the response.

Reconstructing whole entities will be quite an effort though. Plus concurrent edits will make the result as inaccurate as just applying edits locally.

from wikidata-toolkit.

Plus concurrent edits will make the result as inaccurate as just applying edits locally.

Ah that's a good point. Then let's go for just exposing the revision id and not the edited entity.
For the sake of making it easier to return more data in the future without breaking the method signature, I would still wrap this revision id in an object (to which we could add fields later if needed).

from wikidata-toolkit.