Requirement #2615 (closed)
Delete Refactoring and Performance improvements
|Reported by:||jamoore||Owned by:|
|Cc:||cxallan, jburel, wmoore, atarkowska||Business Value:||n.a.|
|Total Story Points:||n.a.||Roif:||n.a.|
|Mandatory Story Points:||n.a.|
Description (last modified by jmoore)
See #2911 for the phase II work on this requirement and http://trac.openmicroscopy.org.uk/omero/wiki/Delete for user-level info on Delete.
The current (4.2.0) implementation of IDelete leaves much to be desired:
- Not enough methods to transactionally handle all deletes
- Too many objects are loaded into memory
- Too few EventLogs are created for some deletes
The intended solution is to have a central definition of "delete specifications" which can be used directly, embedded into one another, or extended by third parties via Spring. These specifications describe the ordered steps (or "delete entries") which will be performed for every id passed to the server. Clients pass any number of "delete commands" to the server for deletion in a single transaction. If any exception is thrown during processing, then all of the deletions are rolled back. Based on client-provided options, some form of exceptions can be safely ignored, so called "SOFT" deletes. Because deletions can take some time, the service is asynchronous and provides a report method as well as a cancellation method.
Each delete command can also pass a string/string map of options. The key values consists of either the absolute path to a particular type like /Image/ImageAnnotationLink/Annotation or a simple path /Annotation, which will then either modify the options for all annotations attached to images or all annotations period. The value consists of one of the option settings below:
- HARD: default option which specifies that a path should be deleted if the user is the owner of the object or its group, or is an admin.
- SOFT: option for paths which should be deleted if possible, but no ConstraintViolationException should be thrown if it's not.
- FORCE: option for paths which should be deleted regardless of permissions and optimistic locks. The only thing which will prevent such a delete is a fatal DB error which will throw a FailedDeleteExcception. Note: it is not possible for non-admin users to specify the FORCE option.
Additionally for annotations, the value of the map can include namespace types which are to be excluded from the delete: "SOFT;excludes=openmicroscopy.org/example".
Change History (25)
comment:3 Changed 10 years ago by jmoore
- Cc cxallan jburel added
- Milestone changed from Unscheduled to OMERO-Beta4.2.1