feat(api): clamp out-of-range construction year to nearest TABULA period - #36
Merged
Merged
Conversation
GET /api/v1/variants/{iso2}/match?type=&year= returned an empty match
list whenever no period band for the requested type covered the given
year. 27 of 93 country+type period sets in the TABULA workbook have no
open-ended (0 or 9999) sentinel band at one or both ends, so a year
before or after the type's recorded range never matched anything
(DE.N.AB only covers 1860-1978, BE.N.AB only covers 1946 onward).
ResolvePeriodByYear now clamps a year outside every band for a type to
the nearest edge: below the oldest band resolves to the oldest period,
above the newest resolves to the newest. A year inside the type's
overall range but falling in a gap between two defined bands is left
as a genuine no-match, since which neighbouring band to prefer there
is undefined.
Also add input guards on the year query parameter: it must be a
non-negative integer and must not exceed the current calendar year.
Closes #34
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GET /api/v1/variants/{iso2}/match?type=&year=returned an empty matchlist whenever no period band for the requested type covered the given
year. 27 of 93 country+type period sets in the TABULA workbook have no
open-ended (0 or 9999) sentinel band at one or both ends, so a year
before or after the type's recorded range never matched anything
(
DE.N.ABonly covers 1860-1978,BE.N.ABonly covers 1946 onward).Change
ResolvePeriodByYearnow clamps a year outside every band for a typeto the nearest edge: below the oldest band resolves to the oldest
period, above the newest resolves to the newest. A year inside the
type's overall range but falling in a gap between two defined bands is
left as a genuine no-match, since which neighbouring band to prefer
there is undefined.
Also adds input guards on the
yearquery parameter: it must be anon-negative integer and must not exceed the current calendar year.
Testing
go test ./...go test -tags integration -v -timeout 10m ./internal/db/repository/and pass after the fix.
Closes #34