| hoo added a comment. |
In T113468#3643791, @daniel wrote:The proposed structure looks good to me. Documentation should make clear that the fields in the structure correspond to usage aspects, and are thus independent of Entity structure.
They aren't equivalent to client usage aspects (they can contain more information, also EntityUsage::TITLE_USAGE is not wiki agnostic), but it should be easy to lay out the relationship.
Note that we have to make sure that we have enough information on the client side to not only determine affected pages, but to also generate the appropriate edit summary (yes, in some cases, we look at the diff to generate a summary on the client side).
This currently only uses ItemChange::getSiteLinkDiff (passed to SiteLinkCommentCreator::getEditComment). I'll probably see what is needed to create this diff from the new structure instead of trying to invent something new.
Depending on their size it might just be ok to use the actual sitelink Diff objects indexed by site id instead of coming up with our own structure, I'll check that.
Also note that the client will currently re-calculate the diff when coalescing consecutive changes. With the new structure, it should be a lot easier to simply merge the diffs. That should be a significant performance gain for the case of coalesced changes. Not sure how much impact that has overall.
This currently loads the full revisions on the client… I'll see what data is needed to do this w/o loading, but this is probably for another time.
It's not clear to me why both representations of the diff should be present in the object if we only include one in the serialization. How would that even work with deserialization? The deserialized version would then have only one diff representation anyway. It seems to me we want to only include the kind of diff that we later want to actually use. Am I missing something?
This was meant for the migration period only, after that is done, only the aspect/ flat diff should be included.
Cc: PokestarFan, hoo, gerritbot, aude, Aklapper, daniel, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
