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