RFE: review new getImagesBySplitFilesets

[jamoore]

See: ​https://github.com/openmicroscopy/openmicroscopy/pull/1214

The new method getImagesBySplitFilesets is working well and will be merged today along with the client PRs. However, there likely will need to be some modifications / extensions such as returning objects rather than ids or similar.

NB: This would be a candidate for an "@Experimental" tag along the lines of "@Deprecated" meaning "This could change in the short-term"

[mtbcarroll]

jburel suggests that,

Since we can access the fileset Id from the image. It will be better to use the id of the passed object or ideally the IObject itself as the key of the returned map instead of the id of the fileset. IObject will be better since we can specify different type but this will imply changing the returned value. Like that we can clearly identify the object we can delete/move

Perhaps we thus end up with something like,

public Map<Class<? extends IObject>, Map<Long, Map<Boolean, List<Long>>>> getImagesBySplitFilesets(
    Map<Class<? extends IObject>, List<Long>> included, Parameters options)

That is, from passed object class, to passed object ID, to included and excluded images.

[mtbcarroll]

​https://github.com/mtbc/openmicroscopy/commit/859130d0c8a9e03f2a4719785602582b57697868 adds notes to the code, warning that the return value may change.

[mtbcarroll]

So, if methods were to return IObjects, must these instances be fairly well-populated ones (e.g., loaded through HQL, maybe with some extra join fetch on some of the X-to-1's), or does it suffice to just new an instance of the appropriate type and do setId on it (or even just to return something like Map.Entry<Class<? extends IObject>, Long>)?

[mtbcarroll]

(no idea why commenting changed the milestone)

[mtbcarroll]

(gah, and that set the version, I hate trac!)

[jamoore]

• Ice keys must be primitives
• The API docs specify whether the IObjects will be loaded or not loaded. (We have instances of both)

[mtbcarroll]

Thanks. The initial work on #11091 should assist here.

If we firmly decide what the API should be, comment here and move into 5.1.0 so we can stabilize API ASAP.

[mtbcarroll]

These changes are now easily effected: see comment prefixing HierarchyNavigatorPlain in PojosImpl.

[hflynn]

Is there an update on this ticket - it's listed on ​https://trello.com/c/WDilK2L3/68-api-model-db-changes-please-update-when-work-is-done

[mtbcarroll]

No update; I didn't list it. Comment 7 still applies. If anyone wants to say what the API should be, then I can certainly effect the change, but I assume that 5.1 is now frozen with regard to breaking changes so that would have to be for 5.2.

[jamoore]

Unless there's a concrete suggestion, I'd think this can be closed. Most likely, Helen, the link from the card was to remind us to finalize the API. Now, by waiting, it is finalized.