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.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #11019 (closed)

Opened 8 years ago

Closed 7 years ago

RFE: review new getImagesBySplitFilesets

Reported by: jamoore Owned by: mtbcarroll
Priority: major Milestone: 5.1.0
Component: API Version: n.a.
Keywords: n.a. Cc: fs@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

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"

Change History (11)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by mtbcarroll

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

comment:3 Changed 8 years ago by mtbcarroll

  • Milestone changed from 5.x to 5.0.0-beta1

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>)?

comment:4 Changed 8 years ago by mtbcarroll

  • Milestone changed from 5.0.0-beta1 to 5.x
  • Sprint FS demo 4.x deleted
  • Version set to 4.4.9

(no idea why commenting changed the milestone)

comment:5 Changed 8 years ago by mtbcarroll

  • Version 4.4.9 deleted

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

comment:6 Changed 8 years ago by jamoore


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

comment:7 Changed 8 years ago by mtbcarroll

  • Owner set to 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.

comment:8 Changed 8 years ago by mtbcarroll

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

comment:9 Changed 7 years ago by hflynn

comment:10 Changed 7 years ago by 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.

comment:11 Changed 7 years ago by jamoore

  • Milestone changed from 5.x to 5.1.0
  • Resolution set to invalid
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.78506 sec.)

We're Hiring!