CWMVUE-634 Implements Access To Water Endpoint #1030
Conversation
rma-bryson
force-pushed
the
feature/Adding_Access_To_Water_Endpoint
branch
from
0670b66 to
1d4ecf3
Compare
There was a problem hiding this comment.
"type" is a bit ambiguous, especially that is is describing the type of parameter (but not to be confused with parameter type inst/ave/const/etc). otherwise the structure looks good. I'd probably prefer parameter even if it doesn't exactly match the parameter in the time series identifier.
… include TimeSeriesIdentifierDescriptor
…resent mapping of location id to mapping of ts-type to ts-id.
rma-bryson
force-pushed
the
feature/Adding_Access_To_Water_Endpoint
branch
from
41be4ec to
4950f40
Compare
|
I don't hate it, but it's not giving me any warm and fuzzies for the future either. @jeffsuperglide, @adamscarberry can you grant @rma-bryson and @adamkorynta at least read access to the access to water repositories to see how you're using the various A2W tables. I don't recall the usage being super high. But since this particular interface and objects will be new to everyone it's a good time to at least consider changes to how the data is presented and I'm not involved enough on the A2W side to say if the proposed design will be sensible. It may just be that these new endpoints are only used for the district level control of things and it may not matter, but better to get a conversation started sooner rather than later. @rma-bryson I would suggest also considering the following scenario to provide a little more insight:
The current example and test has one, which isn't a good sample size for something that could be rather foundational to our various operations. |
|
@MikeNeilson Invites sent to @rma-bryson and @adamkorynta to join a2w-readonly team. You will find the majority of the sql here: https://github.com/USACE/a2w-api/blob/60558999c32d3ea4c0f477812cb5dc53e77e267f/api/models/locations.go#L83-L358 or here: https://github.com/USACE/a2w-api/blob/develop/api/models/timeseries.go @jeffsuperglide is the POC for the a2w-api |
…sts and further updates are needed here, but pausing work for now.
rma-bryson
changed the title
There was a problem hiding this comment.
If I'm understanding these changes I'm not loving them. I picture CwmsId as a lightweight {office,id} pair. If I'm understanding this PR CwmsId now has an additional map of additional properties that it carries with it. Properties are added/removed per instance at runtime and properties can be "required" at runtime. Why are we changing every CwmsId across the application instead of creating a new class that can be used where this is needed? Why even do it dynamically like this? Wouldn't explicitly naming the fields be better, not just for CDA but for documenting the input/output and for our code-gen clients. Whats the performance overhead of this? If I'm reading this right both collections are instantiated whether they are used or not. I think I need to be convinced b/c right now this is a nope from me.
There was a problem hiding this comment.
Perhaps this was written before we had better established the required parameter validation.
But coming back to it a few months later I'm just as confused. We did add, or at least discuss, some flexible properties fields, but there's clearly isn't that even though it read that way on first glance -- until I saw the required and validation everywhere.
There was a problem hiding this comment.
Yeah, I don't remember the exact discussion that lead to the properties map, but I don't love it looking at it now. Doesn't that defeat the whole purpose of having a well-defined schema?
If we want an "id" object that contains kind and bounding office id, then I would think we just make a new ID object that contains those?
No description provided.