Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
- Timestamp:
-
10/18/10 10:09:49 (14 years ago)
- Author:
-
jmoore
- Comment:
-
Legend:
- Unmodified
- Added
- Removed
- Modified
-
|
v22
|
v23
|
|
| 3 | 3 | ---- |
| 4 | 4 | |
| 5 | | The current implementation of IDelete leaves much to be desired: |
| | 5 | == Problem == |
| | 6 | |
| | 7 | The current (4.2.0) implementation of IDelete leaves much to be desired: |
| 6 | 8 | * Not enough methods to transactionally handle all deletes |
| 7 | 9 | * Too many objects are loaded into memory |
| 8 | 10 | * Too few `EventLogs` are created for some deletes |
| 9 | 11 | |
| 10 | | == Notation == |
| | 12 | == Solution == |
| 11 | 13 | |
| 12 | | Below are listed several possible workflows for what a user might want to delete. Each scenario provides the following information: |
| | 14 | 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. |
| 13 | 15 | |
| 14 | | * 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"`. |
| 15 | | * 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` |
| 16 | | * OPTIONS: the paths listed under "OPTIONS" can be handled in on of the following ways: |
| 17 | | * ORPHAN - the objects are left alone, i.e. unlinked from the target. |
| 18 | | * REAP - delete the objects if they would be orphaned. |
| 19 | | * SOFT - delete the objects, but continue if delete is not possible. |
| 20 | | * HARD - delete the objects at all costs. Transaction will fail if not possible. |
| 21 | | * BLOCKER: if this path is filled, then the delete will fail with a `BlockedDeleteException` |
| | 16 | == Options == |
| 22 | 17 | |
| 23 | | == Types == |
| | 18 | 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: |
| 24 | 19 | |
| 25 | | Currently types are separated into two categories. When providing reports to users it should suffice to start at these roots. |
| | 20 | * 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. |
| | 21 | * SOFT: option for paths which should be deleted if possible, but no `ConstraintViolationException` should be thrown if it's not. |
| | 22 | * 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. |
| 26 | 23 | |
| 27 | | === /Roots === |
| 28 | | * /Project and /Dataset |
| 29 | | * /Screen and /Plate, /PlateAcquisition |
| 30 | | * /Image (includes Pixels, binary data, etc.) |
| 31 | | * /Roi (if not already under /Images) |
| 32 | | * /FS - each FS mount is also a root |
| | 24 | 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". |
| 33 | 25 | |
| 34 | | * Note: Delete !TagSet. !TagSet is, from a user perspective, a way of grouping tags. When the user selects the !TagSet, he/she expects an object to be tagged with all the tags "contained" in the !TagSet. When deleting a !TagSet, we should follow the same approach i.e. if the user selects a !TagSet, all the Tags "contained" in the !TagSet should also be deleted. |
| 35 | | === /Orphanable === |
| 36 | | * /TagAnnotation |
| 37 | | * /TermAnnotation |
| 38 | | * /FileAnnotation |
| | 26 | === See also === |
| 39 | 27 | |
| 40 | | '''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.'' |
| 41 | | |
| 42 | | == Pseudo-Scenarios == |
| 43 | | |
| 44 | | Note: the official definition of the scenarios is now available in [source:trunk/components/server/resources/ome/services/delete/spec.xml spec.xml] |
| 45 | | |
| 46 | | {{{ |
| 47 | | REQUEST: /Root/Images |
| 48 | | DELETES: /Root/Images/ImageAnnotationLinks |
| 49 | | /Root/Images/DatasetImageLinks |
| 50 | | /Root/Images/WellSamples (???) |
| 51 | | /Root/Images/Acquisitions |
| 52 | | /Root/Images/Rois |
| 53 | | /Root/Images/{Comments, Ratings, ...} |
| 54 | | /Root/Images/Renderings |
| 55 | | /Root/Images/Thumbnails |
| 56 | | OPTIONS: /Root/Images/Tags |
| 57 | | /Root/Images/Terms |
| 58 | | /Root/Images/FileAnnotations |
| 59 | | }}} |
| 60 | | |
| 61 | | {{{ |
| 62 | | REQUEST: /Root/Datasets |
| 63 | | DELETES: /Root/Datasets/DatasetImageLinks |
| 64 | | /Root/Datasets/DatasetAnnotationLinks |
| 65 | | OPTIONS: /Root/Datasets/Tags |
| 66 | | /Root/Datasets/Terms |
| 67 | | /Root/Datasets/FileAnnotations |
| 68 | | /Root/Datasets/Images - option to delete contents (similar to Eclipse) |
| 69 | | + all options from /Root/Images |
| 70 | | }}} |
| 71 | | |
| 72 | | {{{ |
| 73 | | REQUEST: /Root/Rois |
| 74 | | DELETES: /Root/Rois/Shapes |
| 75 | | /Root/Rois/Shapes/Masks |
| 76 | | BLOCKER: /Root/Images/Rois |
| 77 | | }}} |
| 78 | | |
| | 28 | * The official definition of the delete specifications is available in [source:trunk/components/server/resources/ome/services/delete/spec.xml spec.xml] |
| | 29 | * Examples for using the new delete API are provided in all supported languages under [source:trunk/examples/Delete] |
| | 30 | * For information on having your delete specifications recognized by the server, see ExtendingOmero. |
1.3.13-PRO © 2008-2011
Agilo Software all
rights reserved
(this page was served in: 0.24827 sec.)
