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 #7735 (closed)

Opened 12 years ago

Closed 12 years ago

Bug: import plate with non valid wells

Reported by: jburel Owned by:
Priority: major Milestone: OMERO-4.4
Component: Import Version: n.a.
Keywords: n.a. Cc: jamoore, cxallan, wmoore, mlinkert
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: 2012-01-31 (7)

Description

When I import a plate e.g. flex from test image good.
The plate has only one valid well.
A plate acquisition is always created and the valid well is linked to that plate acquisition. That's the expected behaviour.

At the same time 383 (/384) non valid wells are also created and linked to the plate but not to the plate acquisition.

The problem was highlighted in #7733.
Those 383 objects should not be created in the DB.

Change History (8)

comment:1 Changed 12 years ago by mlinkert

I would guess that this is an artifact of the pre-2010-04 days when the number of rows and columns per plate were not stored explicitly, so the only way to know the size of the original plate was to create all of the wells.

Any reason not to just update all of the HCS readers so that only Wells with associated Images are created (making sure that Plate.Rows and Plate.Columns still show the original plate dimensions)?

comment:2 Changed 12 years ago by jburel

Updating the readers will be a good solution. Chris any reasons not to do it you are thinking of

comment:3 Changed 12 years ago by jburel

  • Sprint changed from 2012-01-17 (6) to 2012-01-31 (7)

comment:4 Changed 12 years ago by cxallan

As we discussed a bit in the office the only reason I can think of not to do this is that when bulk annotation of Plates is performed there is nothing to link to. You'd have to create the Well and annotate that. I agree it's a bit silly when you import, for instance, a 384 Well plate with only one Well and 383 other wells are created but when you look at the opposite and frankly more likely case of a handful of Wells being missing and now you have to add additional logic and messing around to create them it's just not that compelling a case to me.

Bulk annotation of huge numbers of Wells either by spreadsheet or LIMS would be the primary source of annotation data. For the cost of a few extra rows in the database you're making the population of those actual annotations a lot easier.

comment:5 Changed 12 years ago by jburel

Those dummy wells are currently only linked to the Plate not the Plate acquisition so when we browse the plate acquisition they are not loaded. Either way we have some links to add or objects to remove.

comment:6 Changed 12 years ago by jburel

J-M, Chris discussion: some dummy objects could be used to add annotations (manually or via a script), adding them after the fact will probably be too painful. It is certainly not elegant but having a 384 Well Plate with only one valid is certainly not a common use case.
Decision: keep it as it is unless anybody else object?

comment:7 Changed 12 years ago by mlinkert

Leaving things as they are is certainly fine by me.

comment:8 Changed 12 years ago by jburel

  • Resolution set to wontfix
  • Status changed from new to closed

Closing, we keep it as it is.

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.72556 sec.)

We're Hiring!