[jloux-brapi]

Description

Story: BI-2925

• Use brapi dbIds for observation variables instead of trait ids when returned by the BrAPIObservationController.get methods
• Use brapi dbIds for observation variables and related trait, method, and scale objects for the BrAPIObservationVariableController.get methods
• Strip program keys from variableName, scaleName, traitName, and methodName like convertToBrAPI method use to do

Dependencies

• bi-web: epic/BI-2862
• brapi java prodserver: feature/BI-2923

Testing

• Test the BI-BrAPI GET http://localhost:8081/v1/programs/{programDbId}/brapi/v2/variables/{observationVariableDbId}. You will need an auth bearer token from the BrAPI sidebar tab in DeltaBreed. Verify the observationVariableDbId, methodDbId, scaleDbId, traitDbId are all valid brapiDbIds for their associated entity/table.
• Test the BI-BrAPI GET http://localhost:8081/v1/programs/{programDbId}/brapi/v2/variables using different parameters to filter on observation variables, like observationVariableDbId, methodDbId, scaleDbId, traitDbId. These parameters must use the brapi dbIds for these in order to filter properly. You will need a auth bearer token from the BrAPI sidebar tab in DeltaBreed. Verify the observationVariableDbId, methodDbId, scaleDbId, traitDbId are all valid brapiDbIds for their associated entity/table.
• Test the BI-BrAPI GET http://localhost:8081/v1/programs/{programDbId}/brapi/v2/observations using the brapi studyDbId parameters to filter. This studyDbId must be related to the program referenced in the url. These parameters must use the brapi dbIds for these in order to filter properly. You will need a auth bearer token from the BrAPI sidebar tab in DeltaBreed. Verify the observationVariableDbId is a valid brapiDbId for the associated entity/table.
• Test the BI GET http://localhost:8081/v1/programs/{programDbId}/traits/{traitDbId} endpoint. Here, this ID submitted must be from the bi trait table belonging to or shared for the program. You will need an auth bearer token from the BrAPI sidebar tab in DeltaBreed. Verify the observationVariableDbId is a valid brapi id for the table/entity.

Checklist:

• I have performed a self-review of my own code
• I have tested my code and ensured it meets the acceptance criteria of the story
• I have create/modified unit and/or integration tests to cover this change or tests are not applicable
• I have commented my code, particularly in hard-to-understand areas
• I have either updated the source of truth or arranged for update with product owner if needed https://breedinginsight.atlassian.net/wiki/spaces/BI/pages/1559953409/Source+of+Truth

[humsika]

This strips only the current program’s key. For a program subscribed to a shared ontology, variables are stored with the owner’s key, so the single GET returns names like Height [OWN] while the list shows Height. Also, getObservationVariableName() isn’t null-checked like the scale/method/trait names, so a null name throws an NPE inside removeProgramKey.

[jloux-brapi]

I removed these changes in favor of unifying the response data between the get by dbId and the general GET, so this comment is not relevant anymore I think.

[humsika]

Agreed, thanks. Searching only the program’s traits covers it.

One thing I noticed: the lookup on line 161 of the controller uses traitService.getByProgramId, which doesn’t follow subscribed ontologies, while the list uses ontologyService.getTraitsByProgramId. So for a subscribed program, the list shows a variable but GET by its id returns 404. Could we switch to ontologyService.getTraitsByProgramId(programId, true)? (OntologyService is already injected into BrAPIObservationVariableService but isn’t used.)

[jloux-brapi]

As discussed in Slack, to me this is an existing bug I'm not sure I want to handle in the glob of code that is the cache removal branch.

I think it would be worth discussing the problem with the team, so I made this ticket for the effort. We can discuss at next backlog refinement.

[humsika]

Thanks!