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

Opened 6 years ago

Closed 6 years ago

Acquisition dates should be null if unknown

Reported by: wmoore Owned by: mtbcarroll
Priority: critical Milestone: 5.1.0-m1
Component: Model Version: n.a.
Keywords: n.a. Cc: mlinkert, jamoore, ajpatterson
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.


Currently the OMERO DB does not allow empty Acquisition dates for images:

omero50=# \d image;
                     Table "public.image"
       Column       |            Type             | Modifiers 
 id                 | bigint                      | not null
 acquisitiondate    | timestamp without time zone | not null

This means that you cannot tell whether the image was acquired on a particular date or if that date was simply auto-populated with the import date at import time.

Need to allow NULL import dates in the OMERO DB (and OME model?) and Bio-Formats should not populate this value on import unless we know Acquisition date from image metadata.

Then, clients should not show Creation Date in place of Acquisition Date in the right panel and in search results. Should just show empty Acquisition Date if not in the DB.

Change History (11)

comment:1 Changed 6 years ago by mtbcarroll

Andrew says that it's optional in the schema. Would a 5.1 milestone be okay for this DB & BF change? This will break clients that assume it's not null so don't check on retrieval.

comment:2 Changed 6 years ago by wmoore

  • Milestone changed from 5.0.4 to 5.1.0

OK, 5.1 is fine.

comment:3 Changed 6 years ago by jamoore

  • Milestone changed from 5.1.0 to 5.1.0-m1
  • Priority changed from major to critical

This may also be a good opportunity for testing "Ask Bio-Formats if there is an acquisition date". Further, if the timestamp matches import, it can be nulled.

Moving to m1 since model changes need to get in rather quickly.

comment:4 Changed 6 years ago by mtbcarroll

  • Status changed from new to accepted

comment:5 Changed 6 years ago by mtbcarroll

  • Resolution set to fixed
  • Status changed from accepted to closed

Fixed by but there may well be follow-up tickets due to the implications of making something newly nullable, though much of our older code already seems to expect that acquisition date might be null. Especially, the acquisition date might sometimes be getting filled in needlessly.

comment:6 Changed 6 years ago by jamoore

That the older code is doing checks does make some sense since previously the field *was* nullable.

comment:7 Changed 6 years ago by mtbcarroll

Actually, given the title of this ticket, now that the dates are no longer not nullable in the DB, one could just reopen this instead and assign it to someone who is better for the part where we make sure that unknown acquisition dates really are null (e.g., deciding when it is appropriate to use file modification times) -- up to you guys. I am happy to assist where it's clear what should be done.

comment:8 Changed 6 years ago by wmoore

  • Resolution fixed deleted
  • Status changed from closed to reopened

What is the import step that auto-populates Acquisition Date with the current date if Acquisition Date is null? This needs to be fixed so that this does not happen.

comment:9 Changed 6 years ago by mtbcarroll

I've looked at a bunch of what might be relevant code, in the server and in Bio-Formats, but I haven't been able to put together a coherent story so far -- I wouldn't want to mess with it without the blessing of whoever already knows their way around it and knows why it's as it currently is.

comment:10 Changed 6 years ago by mtbcarroll

I may have found an approach that has import leave the acquisition date null when appropriate. I'll add that in a separate PR once the main one is in so that it can get proper attention in review.

comment:11 Changed 6 years ago by mtbcarroll

  • Resolution set to fixed
  • Status changed from reopened to closed

Added commits to above PR.

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

We're Hiring!