Description
For example, in the isisaddons' todoapp this shows up as an issue if mark an item (with a non-null dueBy) as done, then attempt to modify the dueBy date via edit. What we see is no message shown, followed then by an invalid concurrency exception.
With the simpleapp it's possible to get a similar behaviour.
~~~
On analysis, there are several issues:
- the concurrency exception is caused by the todo item becoming dirty when the change is applied (prior to being rolled back via Isis' memento); the todo item's adapter's Oid's version is updated as a side-effect of this (the postStore lifecycle callback), and thereafter we see the concurrency exception
- this can in some cases be suppressed (eg for the simpleapp) by performing a rollback of the xactn if the validate() has failed... this should be done anyway
- however in more complex cases (such as todoapp) the updating of the setVersion happens during the "apply()" of changes, which will still trigger the subsequent concurrency exception
- the root cause here is that the memento being taken does not also reinstate the version of the target object.
- the wicket viewer's EntityPropertiesForm was not passing through an AjaxRequestTarget for repainting [nb: this may be a red-herring, but fixing this does no harm]
So, to sum up the fixes:
- abort the xactn if validate() vetoes the save
- improve the memento so that version is reinstated
- pass through AjaxRequestTarget
~~~~~~~~
Note that there is a related, not yet tackled issue... namely that validate() isn't enforced for action invocations, only when modifying an object by editing. Have raised ISIS-1156 for this.
Attachments
Issue Links
- duplicates
-
CAUSEWAY-1072 When editing, if property validation vetoes the save, then not handled correctly.
-
- Closed
-