LocationLevel retrieve constant values in time window - #887
Conversation
…t values. Includes tests to verify functionality
| + "specified), as well as the time zone of any times in the response." | ||
| + " If this field is not specified, the default time zone of UTC " | ||
| + "shall be used."), | ||
| @OpenApiParam(name = START, type = Instant.class, description = "Specifies the start of the time " |
There was a problem hiding this comment.
Adding a start and end date for getOne does not make sense to me as it conflicts with the effective date parameter.
There was a problem hiding this comment.
That's fair, but because there are multiple effective dates there does need to be a way to retrieve them all without it necessarily being a "timeseries" as that's a different concept (seasonal, etc) of location level.
There was a problem hiding this comment.
I don't see how that's different than the behavior of the getAll endpoint.
There was a problem hiding this comment.
We'll see how Daniel responds.
There was a problem hiding this comment.
@DanielTOsborne Following up for your thoughts on this
There was a problem hiding this comment.
@DanielTOsborne or @MikeNeilson Can we get a decision on this? If we can't decide what makes sense for getOne we could always not have a getOne and force users through getAll. I guess I'd like to see this merged and a new issue/pr opened to figure out next steps. People could try this out in the meantime
There was a problem hiding this comment.
Agreed. I believe people are already using the getOne though so I don't think we should remove it at this time. But PR itself should be appropriately updated and the work merged so we can move on.
If we don't get responses during development we're definitely going to get them after release.
|
Closing since branch is too out of date to reasonably merge. Superseded by PR: #1202 |
4 participants
Fixes #599, LocationLevel retrieve constant values in time window. Includes tests to verify functionality