Bug: Delete(OriginalFile) misses pixels link

[jamoore]

Deleting an archived original file causes:

~/git/dist/lib/python $ python ../../alex.py 
[[901L]]
f75da5b5-611f-499e-8b0a-9c8b3d3f1429/DeleteHandleffdee848-26c9-435f-a074-afe84885805c -t:tcp -h 192.168.178.32 -p 50858
[object #0 (::omero::api::delete::DeleteReport)
{
    command = 
    {
        type = /OriginalFile
        id = 901
        options = 
        {
        }
    }
    error = ConstraintViolation: fkpixelsoriginalfilemap_parent_originalfile

The spec will need to be modified:

    <bean parent="delSpec" name="/OriginalFile">
        <constructor-arg>
            <list>
                <value>/OriginalFile/OriginalFileAnnotationLink;FORCE</value>
                <value>/Annotation;SOFT;/OriginalFile/OriginalFileAnnotationLink</value>
                <value>/OriginalFile</value>

Found while working on ​https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=919

[jburel]

When deleting the archived image, the archived flag in the image table must be set to false.

[jmoore]

The following change:

@sprint6-server-backlog ~/git/components/server $ git diff
diff --git a/components/server/resources/ome/services/delete/spec.xml b/components/server/resources/ome/services/delete/spec.xml
index 9e55e9a..3d2c4d5 100644
--- a/components/server/resources/ome/services/delete/spec.xml
+++ b/components/server/resources/ome/services/delete/spec.xml
@@ -316,6 +316,7 @@
     <bean parent="delSpec" name="/OriginalFile">
         <constructor-arg>
             <list>
+                <value>/OriginalFile/PixelsOriginalFileMap;FORCE</value>
                 <value>/OriginalFile/OriginalFileAnnotationLink;FORCE</value>
                 <value>/Annotation;SOFT;/OriginalFile/OriginalFileAnnotationLink</value>

allows the following to complete as expected:

omero import -a test.png
omero hql "select p from OriginalFile p order by p.id desc" # get ID
omero delete /OriginalFile:1402

BUT it doesn't modify the "archived" flag. Should we not prevent the deletion if there's a PixelsOriginalFileMap so that another API has to be used? But if so, what is that API and how do we go about modifying the image? I could detect the deletion of the POFMap -- though we don't have anything like that in place.

Passing off to jburel for consideration. Feel free to pass back to me or off to someone else for more feedback.

I'll push this change to my sprint6-server-backlog branch for the moment, though we may want to revert it.

[jburel]

Following a discussion I had with Chris this morning about delete.

• Deleting original file should be available in client e.g. archived image. see #7753
• If the original file has been deleted and the flag is still on. That's not too bad for now. We will just need to make sure that we handle that case in client.#7754 The archived problem should go away when we have FS in place. Delete of original file in general will have to be dealt with care.

[jburel]

Passing it to Will for comments

[wmoore]

I think that sounds OK. Clients just need to remember to remove the flag once file is deleted.

[wmoore]

This is closed now, right?

[jmoore <josh@…>]

(In [b7cdfecdaacc0efe4f0c1ea50195f7bf4531c1aa/ome.git] on branch develop) Delete pixelsOriginalFileMaps for archived images (See #7300)