Requirement #2615 (new)
Opened 14 years ago
Last modified 13 years ago
Delete Refactoring and Performance improvements — at Version 7
Reported by: | jamoore | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | OMERO-Beta4.2.1 |
Component: | n.a. | Keywords: | n.a. |
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)
The current 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
Notation
Below are listed several possible workflows for what a user might want to delete. Each scenario provides the following information:
- REQUEST: the user request for what type should be deleted (ids are omitted). Types are represented as xpath-like statements, some which don't actually exist as types "Comments" represent a combination of fields, like type=Annotation + namespace="comment".
- DELETES: the types which would 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
- OPTIONS: the paths listed under "OPTIONS" can be handled in on of the following ways:
- ORPHAN - the objects are left alone, i.e. unlinked from the target.
- REAP - delete the objects if they would be orphaned.
- SOFT - delete the objects, but continue if delete is not possible.
- HARD - delete the objects at all costs. Transaction will fail if not possible.
- BLOCKER: if this path is filled, then the delete will fail with a BlockedDeleteException
Types
Currently types are separated into two categories. When providing reports to users it should suffice to start at these roots.
/Roots
- /Projects and /Datasets
- /Screens and /Plates
- /Images (includes Pixels, binary data, etc.)
- /Rois (if not already under /Images)
- /FS - each FS mount is also a root
/Orphanable
- /Tags
- /Terms
- /FileAnnotations?
NB: We may want to consider whether or not there should be two types of annotations. Ones which are orphanable and ones which are not.
Scenarios
REQUEST: /Root/Images DELETES: /Root/Images/ImageAnnotationLinks /Root/Images/DatasetImageLinks /Root/Images/WellSamples (???) /Root/Images/Acquisitions /Root/Images/Rois /Root/Images/{Comments, Ratings, ...} /Root/Images/Renderings /Root/Images/Thumbnails OPTIONS: /Root/Images/Tags /Root/Images/Terms /Root/Images/FileAnnotations
REQUEST: /Root/Datasets DELETES: /Root/Datasets/DatasetImageLinks /Root/Datasets/DatasetAnnotationLinks OPTIONS: /Root/Datasets/Tags /Root/Datasets/Terms /Root/Datasets/FileAnnotations /Root/Datasets/Images - option to delete contents (similar to Eclipse) + all options from /Root/Images
REQUEST: /Root/Rois DELETES: /Root/Rois/Shapes /Root/Rois/Shapes/Masks BLOCKER: /Root/Images/Rois
Change History (7)
comment:1 Changed 14 years ago by jmoore
- Priority changed from major to critical
comment:2 Changed 14 years ago by jmoore
comment:3 Changed 14 years ago by jmoore
- Cc cxallan jburel added
- Milestone changed from Unscheduled to OMERO-Beta4.2.1
comment:4 Changed 14 years ago by jburel
- Cc wmoore added
- Description modified (diff)
comment:5 Changed 14 years ago by jburel
- Cc ome-nitpick@… added
comment:6 Changed 14 years ago by jmoore
- Description modified (diff)
comment:7 Changed 14 years ago by jmoore
- Description modified (diff)
Notes from discussion (Jean-Marie, Josh, Chris):