Conservative MIF graphs

[jamoore]

​spec.xml defines a number of graphs which can be used for deleting, chgrp'ing, etc. The current definitions are such that operating on an "/Image" walks up the graph to "/Fileset" and then back down to all other "/Images" inside the fileset.

The default behavior should become that chosing a single image in a MIF only operates on that image. This will lead to failures without special client handling. For delete, a "SOFT" option will make the deletion take place on the single image (which was considered acceptable).

Specific changes that need to be made

• spec.xml modified.
• Guarantee that a detectable error message is present on failure. (see #10779, etc)
• In cooperation with #10777 (i.e. without conflicts) tests reviewed.

Warn/Error? states

• When SOFT is passed for delete (likely to become the default for images. see #10779), it return value should contain list of filesets which were not completely deleted. This would allow the client to say "The data itself didn't get deleted becuase it's used by 5 more images"

[jamoore]

Petr filed this as a bug in #10460 which included specific real files that can be tested.

[mtbcarroll]

My present impression is that spec.xml has a bean named /Image that includes the /Fileset;HARD;/Image path that can perhaps be SOFTened. GraphSpec's comments include some explanation of these paths and GraphOpts.Op's comments explain HARD and SOFT. This path drives DeleteStep which appears to delete database entries.

A delete request comes in through DeleteI which uses a Deletion to both drive DeleteStep and then delete the actual files whose database entries DeleteStep has removed.

[jamoore]

That sounds correct. Other than just changing the configuration (which we can do) the problems we're facing are:

• there's no way to have different setting for delete and chgrp steps (here the chgrp shouldn't be SOFT)
• the clients need more feedback on what's blocking the chgrp (e.g. "fileset:5 is blocking the chgrp)

These are essentially design issues in the graph parsing that we'll have to be re-considered.

[jamoore]

Changes made in ​https://github.com/openmicroscopy/openmicroscopy/pull/1142 On-going discussion there in an attempt to get #10842 / ​PR 1139 tests passing. Closing this ticket, though follow-up work is necessary (See #10846 and #10847, though likely both can't be completed for demo 4.1)

[jmoore <josh@…>]

(In [eb9275e6306a2b76036d133d0508725a03c8e55f/ome.git] on branch develop) Restrict chgrp of filesets and return constraints (See #10776)

With this change filesets will no longer be moved along with
images, and the dangling filesets will cause the chgrp to
fail. The ids of the filesets causing this can be found in
the "constraints" field of the "omero.cmd.ChgrpERR" response.

[jmoore <josh@…>]

(In [fc6b8340236c006c64043c22296268bddb11ea14/ome.git] on branch develop) Remove +FS logic in graphs (Fix #10776)

For previous FS milestones, /Dataset and /Image specs
were modified to automatically handle the extra objects
linked to by /Filesets, including other images. With these
changes, that logic has now been completely removed.

Instead, the /Fileset relationship is marked SOFT so
that in order to pass chgrp validation, it is necessary
to have all /Images moved at once.

Current limitations:

• ​https://trac.openmicroscopy.org.uk/ome/ticket/10846 Multiple failing filesets will not be detected.

• ​https://trac.openmicroscopy.org.uk/ome/ticket/10847 Passing individual images will not succeed.

[jmoore <josh@…>]

(In [b331a205e491f0b3c0bdb78569c8e000b16dd747/ome.git] on branch develop) Fix Plate delete (Fix #11009, See #10776)

fc6b8340236c006c64043c22296268bddb11ea14 removed the
"+WS" suffix from Image, which broke plate delete.
Essentially, the Image subgraph was not being processed
but just the image table itself.

[Josh Moore <josh@…>]

(In [7cb6bff0114b30a3525504dc02bb966f123284f3/ome.git] on branch develop) Merge pull request #1225 from joshmoore/11009-plate-delete

Fix Plate delete (Fix #11009, See #10776)