getQueryString includes externalInfo

[will-moore]

See ome/omero-web#613.

This updates getQueryString (which builds queries for conn.getObject() and for JSON API) to include externalInfo.

So, all the "top level" objects will now include externalInfo if it exists.

E.g. going to /api/v0/m/plates/51/wells/ we will see externalInfo on the Wells, but not on the child Images.

For that we'd have to also update various queries. E.g. BlitzGateway Well._getQueryString() would need:

             query += " left outer join fetch obj.wellSamples as wellSamples"\
                      " left outer join fetch wellSamples.image as image"\
+                     " left outer join fetch image.details.externalInfo "\
                      " left outer join fetch wellSamples.plateAcquisition"\
                      " as plateAcquisition"

[will-moore]

NB: although we only get 3 useful fields from externalInfo, the JSON is quite verbose. So if we're loading all the Wells from a Plate, and they all have externalInfo, it will increase the JSON parsing and data size a fair bit (not quantified):

{
  "externalInfo": {
    "@type": "TBD#ExternalInfo",
    "@id": 4,
    "omero:details": {
      "@type": "TBD#Details",
      "owner": {
        "@type": "http://www.openmicroscopy.org/Schemas/OME/2016-06#Experimenter",
        "@id": 2,
        "omero:details": {
          "@type": "TBD#Details",
          "permissions": {
            "@type": "TBD#Permissions",
            "perm": "rw----",
            "canAnnotate": true,
            "canDelete": false,
            "canEdit": false,
            "canLink": true,
            "isWorldWrite": false,
            "isWorldRead": false,
            "isGroupWrite": false,
            "isGroupRead": false,
            "isGroupAnnotate": false,
            "isUserWrite": true,
            "isUserRead": true
          }
        },
        "FirstName": "Will",
        "MiddleName": "J",
        "LastName": "Moore",
        "Email": "",
        "UserName": "will"
      },
      "group": {
        "@type": "http://www.openmicroscopy.org/Schemas/OME/2016-06#ExperimenterGroup",
        "@id": 3,
        "omero:details": {
          "@type": "TBD#Details",
          "permissions": {
            "@type": "TBD#Permissions",
            "perm": "rwra--",
            "canAnnotate": true,
            "canDelete": false,
            "canEdit": false,
            "canLink": true,
            "isWorldWrite": false,
            "isWorldRead": false,
            "isGroupWrite": false,
            "isGroupRead": true,
            "isGroupAnnotate": true,
            "isUserWrite": true,
            "isUserRead": true
          }
        },
        "Name": "Swedlow Lab"
      },
      "permissions": {
        "@type": "TBD#Permissions",
        "perm": "rwra--",
        "canAnnotate": true,
        "canDelete": true,
        "canEdit": true,
        "canLink": true,
        "isWorldWrite": false,
        "isWorldRead": false,
        "isGroupWrite": false,
        "isGroupRead": true,
        "isGroupAnnotate": true,
        "isUserWrite": true,
        "isUserRead": true
      }
    },
    "EntityId": 3,
    "EntityType": "com.glencoesoftware.ngff:multiscales",
    "Lsid": "test_extinfo_path"
  }
}

[sbesson]

Would this be an opportunity to tackle ome/omero-marshal#22 and normalize these redundant objects?

[will-moore]

@sbesson Hmmm - yesssss, but how to "normalise" without it being a breaking API change?
A lot of the time we just want to ignore details (e.g. on externalInfo) but to give the user control over that gets pretty complex.
Either way it's a big change to omero-marshal.

[sbesson]

Agreed. If we were considering integrating other changes like ome/omero-marshal#84, this would most certainly increment the version of the OMERO JSON API and be a good time to make these changes

[will-moore]

Ooops - forgot that I had opened this already. Closing in favour of #453