[Spike] Investigate impact of error logging on the bulk edit performance
Scenarios:
| № | Scenario | Upload the file with identifiers, min | Display the preview of the changes, min | Display the confirmation screen, min |
|---|---|---|---|---|
| 1 | Set status to Available when all items have already status Available | 5,3 | 1,6 (large time due to the entities equality comparison on this stage) | 0,02 (small time due to the fact that there are no update requests) |
| 2 | Set status to Unknown when all items have status Available | 6,0 | 0,1 | 4,7 |
| 3 | Clear permanent location when most records have permanent location populated | 6,2 | 0,5 | 4,7 |
| 4 | Change the value of the permanent location to a new value | 6,1 | 0,1 | 4,6 |
Results:
1) A single anomalous case was found - all records do not require changes since the verification of the identity of entities is carried out at the stage of applying changes to entities.
2) There are two possibilities to reduce the time of the stage: a) move the logic of checking the identity of entities to the commit stage b) optimization of the entity comparison logic to increase performance.
Approaches:
a) Move the comparison logic to commit stage.
Main cons - a lot of code reworking. The process will move to the commit stage, which will require a complex code rewrite to ensure errors are accessible on the "Are you sure?" form.
a) Optimisation of the entities equality comparison logic.
Main cons - Significant performance improvement may not be achieved.
Summary
Because on "Are you sure?" form does not show errors, then it makes sense to move the logic of checking the identity of entities to the commit stage. Moreover, optimization of the method will not significantly reduce the verification time.