Page MenuHomePhabricator

[4h spike] Research how to implement entity rollback on cancel
Closed, ResolvedPublic


We spent quite some time thinking about this in task breakdown. @Pablo-WMDE will probably pick this up on 15/04/19 but if not then this task description will need improving.

In task breakdown we discussed 3 possible solutions to rolling back to the pre-editmode state of the entity. They are:

  1. Re-request the revision ID from one of our repositories and recall the ENTITY_UPDATE action. We know this won't work out of the box after having done a successful save action. In this case we could either cache each revision and have the reposity reply with that or we could just remake the request.
  2. keep a copy of the "clean" entity in the store and use this. In this case at most 2 copies of an entity would be there (1 the version bound to the input fields and 2 the clean base copy)
  3. roll back each atomic mutation until we're back where we started

After this timebox we'd like to know for each of the options (1-3):

  1. How much effort is involved in creating a revision aware entity repository in the client
    • should this implementation come with caching or is it premature optimisation
  2. Should this be portable to any part of the store or is it encapsulated within the entity namespace
  3. how much effort is involved in the atomic rollbacks
    • how much code we would then need to maintain
    • how much we would bloat out production bundle with this

Event Timeline

Change 504857 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[wikibase/termbox@master] Cancel: roll back entity changes

I created in the awareness that it does not satisfy the definition of research but rather is a prototypical implementation along the general concept of approach n°2 from the description.
It is a result of looking at the use case we try to tackle and implementing the smallest conceivable (while still viable) solution - please verify. Its existence also pays tribute the fact that approach n°3 feature wise greatly exceeds all existing requirements, and approach n°1 - though conceptually sound - can factually be considered a super set of approach n°2 (granted with different means but eventually: keeping a shadow copy).
If we go with this approach let's discuss if we should still create story for making client/EntityRepository obey its parameters even if there is no active use of it.

Change 504857 merged by jenkins-bot:
[wikibase/termbox@master] Cancel: roll back entity changes