FM2-653 #556
FM2-653 #556
Conversation
api/src/main/java/org/openmrs/module/fhir2/api/dao/impl/BaseDao.java
Outdated
Show resolved
Hide resolved
| @@ -38,6 +41,8 @@ | |||
| @Setter(AccessLevel.PACKAGE) | |||
| public class FhirLocationDaoImpl extends BaseFhirDao<Location> implements FhirLocationDao { | |||
|
|
|||
| private static final int SUPPORTED_LOCATION_HIERARCHY_SEARCH_DEPTH = 9; | |||
There was a problem hiding this comment.
Basically, I use a succession of joins to go back up the ancestor tree. A bit annoying/hacky, but from a practical matter, seems unlikely there would ever be a hierarchy of more than 9 levels. We could make this a configurable parameter if we wanted.
| private void handleAncestorLocation(Criteria criteria, ReferenceAndListParam ancestor) { | ||
|
|
||
| List<Criterion> elementOrAncestorEqualsReferenceCriteria = new ArrayList<>(); | ||
| Optional<Criterion> elementEqualsReferenceCriterion = handleLocationReference(ancestor); // note: "below" is inclusive of the element itself |
There was a problem hiding this comment.
| @@ -113,6 +113,9 @@ public IBundleProvider searchLocations(@OptionalParam(name = Location.SP_NAME) S | |||
| @OptionalParam(name = Location.SP_PARTOF, chainWhitelist = { "", Location.SP_NAME, Location.SP_ADDRESS_CITY, | |||
| Location.SP_ADDRESS_STATE, Location.SP_ADDRESS_COUNTRY, | |||
| Location.SP_ADDRESS_POSTALCODE }, targetTypes = Location.class) ReferenceAndListParam parent, | |||
| @OptionalParam(name = "below", chainWhitelist = { "", Location.SP_NAME, Location.SP_ADDRESS_CITY, | |||
There was a problem hiding this comment.
So it sounds like @ibacher this extra parameter should not be here, and this new functionality should just be part of the "SP_PARTOF" parameter above? I was having a problem with that, see my follow on comment and screenshot in the test case below.
There was a problem hiding this comment.
The tl;dr is that if I change this to name="partof:below" any parameter passed in that way gets assigned to both the ReferenceAndListParam ancestor and ReferenceAndListParam parent.
And if I remove the "below" parameter, I'm not quite sure how to parse the "parent" ReferenceAndListParam to tell if this should be a standard "partof" vs a "partof:below"
There was a problem hiding this comment.
this extra parameter should not be here, and this new functionality should just be part of the "SP_PARTOF" parameter above?
Ideally, yes.
And if I remove the "below" parameter, I'm not quite sure how to parse the "parent" ReferenceAndListParam to tell if this should be a standard "partof" vs a "partof:below"
That's very problematic. The problem is that partof=123abc&partof:below=456def is technically valid and I'm not quite sure what HAPI would do with that...
| @@ -483,6 +486,31 @@ public void shouldSearchForExistingLocationsAsJson() throws Exception { | |||
| assertThat(entries, containsInRelativeOrder(hasResource(hasProperty("name", equalTo("Test location 6"))), | |||
| hasResource(hasProperty("name", equalTo("Test location 8"))))); | |||
| assertThat(entries, everyItem(hasResource(validResource()))); | |||
|
|
|||
| // search by ancestors | |||
| response = get("/Location?below=" + LOCATION_ANCESTOR_TEST_UUID).accept(FhirMediaTypes.JSON).go(); | |||
There was a problem hiding this comment.
So when I changed this to "Location?partof:below=" it was getting picked up by the ResourceParam, but the "below" was being set to the ResourceType. This seems incorrect? Isn't the type of this resource a location?
| handleLocationReference("loc", parent).ifPresent(loc -> criteria.createAlias("parentLocation", "loc").add(loc)); | ||
| private void handleLocationReference(Criteria criteria, ReferenceAndListParam locationAndReferences) { | ||
|
|
||
| if (locationAndReferences == null) { |
There was a problem hiding this comment.
All this through 148 is basically a series null / size checks to make sure that ReferenceAnd list only contains a single reference. We probably should change this parameter to just a ReferenceParam but I didn't want to untangle the locationReference utility method at this point.
Basically, the "partof:below" functionality I built currently only works correctly for a single parameter (and I don't have the need to build more now). Technically the plain "partof" works for multiple "partof", but would always return null since a location partof is 0..1
Description of what I changed
Issue I worked on
https://openmrs.atlassian.net/browse/FM2-653
Checklist: I completed these to help reviewers :)
My IDE is configured to follow the code style of this project.
No? Unsure? -> configure your IDE, format the code and add the changes with
git add . && git commit --amendI have added tests to cover my changes. (If you refactored
existing code that was well tested you do not have to add tests)
No? -> write tests and add them to this commit
git add . && git commit --amendI ran
mvn clean packageright before creating this pull request andadded all formatting changes to my commit.
No? -> execute above command
All new and existing tests passed.
No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.
My pull request is based on the latest changes of the master branch.
No? Unsure? -> execute command
git pull --rebase upstream master