location levels level-id-mask not allowing wild card

[MikeNeilson]

https://cwms-data.usace.army.mil/cwms-data/levels?level-id-mask=ckvt1%2A&office=lrn

Query doesn't not return error but also doesn't return data.

[rma-rripken]

Couple of things going on in that request. When I try it out I get back:

Processed At ecpcw6kbaaa4i03:S0CWMSZ1

Time Of Query 02-Feb-2023 22:40 UTC

Process Query 3201 milliseconds

Format Output 0 milliseconds

Requested Start Time 01-Feb-2023 22:40 UTC

Requested End Time 02-Feb-2023 22:40 UTC

Requested Format TAB

Requested Office LRN

Requested Names ckvt*

Requested Units EN

Requested Datums NATIVE

Total Location Levels Cataloged 0

Unique Location Levels Cataloged 0

Office Name Attribute Alternate Names

Those comments with the hash come from pl/sql. You'd only get that output if you use the older style calls that delegate directly to pl/sql.

If I get rid of the level-id-mask field and leave it blank than I get back a list of locations but none of them start with ckvt - what is that an alias for? It looks like the pl/sql output is including some level-id aliases but maybe not all of them.

Strangely if I put a in the level-id-mask field I don't get any output. That seems like a bug. Looking at the code it looks like not providing anything in field field sends a null to the pl/sql. So the behavior of the pl/sql is different whether it gets a null or "".

When no mask was provided I saw ALPT1 in the output. We should be able to test the mask by using something like ALP*. Sure enough - I get back 3 levels that start with ALPT1.

In the full list I saw Wolf Creek. For example this line:

LRN Wolf Creek Dam.Stor.Inst.0.Bottom of Flood KY03010.Stor.Inst.0.Bottom of Flood WLCK2.Stor.Inst.0.Bottom of Flood WOL.Stor.Inst.0.Bottom of Flood

If I put in WOL I should get back those levels. But when I try that I get a System Error. Hmmm. W also causes a System Error. KY causes a System Error. K causes a System Error. hmm. those seem like they should work.

[rma-rripken]

If we try the JSONv2 end-point things are a little different.
First is the begin/end dates. The query for the v2 end-point constrains the AV_LOCATION_LEVEL LEVEL_DATE to be between the start and the end. Its possible this isn't the correct thing to do - please advise if the dates should be handled differently.

So to test the v2 end-point we probably need to specify a begin date that is far in the past. I suggest 1999-01-01T00:00:00Z Providing the officeId and that begin date and leaving the mask field empty I get back a page of levels starting with JPHT1 and ending at WOLF_CREEK. I didn't count them but it doesn't seem to have the same number of results.

Its not in the documentation but I know that the JSONv2 end-point treats the mask as a regex - not a glob style mask like the pl/sql uses. To get just the JPHT levels I could use a mask like: JP.* Entering that in I get back 5 levels at JPHT1

In the pl/sql results there were levels at ALPT1 - we should be able to get those back with a mask like ALP. - But this isn't working. Hmm. If I shorten the mask to A. I get levels back but not at ALTP1. It looks like I get back all the levels that have the letter a in them. I can change the regex to: ^A.* Then I should get back all the levels where the name starts with the level "a" - this returns []. Going back to the JsonV1 output the levels at ALPT1 had aliases with locations like "1762F4A8" and "1762F4A8-WFkObeyR-AlpineTN" and "ALPT1-WFkObeyR-AlpineTN" - seems like we should be able to find one of those. But no.
Something is not right.

[rma-rripken]

Turns out 1999 isn't far enough back. There are a bunch of levels at 1900-01-01. If I set the begin date to 1800 then I do get ALPT1 in the results.

[rma-rripken]

Perhaps the swagger documentation needs to highlight or emphasize that the end-points can have different behavior depending on whether they go through the legacy format or the newer JSONv2 formats. Maybe the controllers that have the older "format" argument need to have an html a link to a support page describing how the request are different and how to get clients to add accept version=2 to their requests? I don't think there is anything code-wise that needs to happen

[MikeNeilson]

That's a good idea.

[rma-rripken]

We need to link a legacy.html to all the end-points that have a format= parameter with description of whats going on and the difference between pl/sql and cda responses. The page should include screenshot of curl and wget cmd options and example code in python and javascript of how to issue requests with accept-header