Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DM-28004: ExposureInfo may persist dummy FilterLabels #554

Merged
merged 1 commit into from Dec 14, 2020

Conversation

kfindeisen
Copy link
Member

This PR enforces the convention that ExposureInfo::getFilter() == Filter() corresponds to ExposureInfo::getFilterLabel() == nullptr at the translator level rather than the ExposureInfo constructor level. This prevents spurious "_unknown_" FilterLabels from getting persisted as part of new Exposures.

Copy link
Contributor

@parejkoj parejkoj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only question is whether we could have a test here (or in obs_base?) that confirms/demonstrates this behavior. If that requires persisting a FITS file without a Filter defined, then don't bother, but if it's a trivial test?

Also, does this require changing the docstrings for ExposureInfo or the FitsReader?
A quick skim of the docs (and a reminder that the guts are a StorableMap now) suggests not, but I'm not positive.

The check's previous location in the ExposureInfo constructor allowed
some old Filter code to bypass it, storing "unknown" FilterLabels.
@kfindeisen kfindeisen merged commit 484459b into master Dec 14, 2020
@kfindeisen kfindeisen deleted the tickets/DM-28004 branch December 14, 2020 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants