issues 3242 and 3265 - scope search-system and search-history for fhirVersion#3268
Merged
Conversation
This changeset adds a JAX-RS RequestFilter that sets a requestContext property, "com.ibm.fhir.server.fhirVersion" with the following order of precedence: 1. "4.3" from the acceptableMediaTypes 2. "4.0" from the acceptableMediaTypes 3. whatever is configured in the fhirServer/core/defaultFhirVersion config property 4. "4.0" Additionally, I updated the Capabilities resource to use the fhirVersion from the request context instead of processing the Accept header itself. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
punktilious
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
tbieste
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
punktilious
reviewed
Feb 2, 2022
tbieste
approved these changes
Feb 2, 2022
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
1. introduce enums and utilities for working with resource type names
and fhirVersion values ('4.0' and '4.3')
2. use those to provide a better abstraction for working with the
fhir-server-config `fhirServer/resources` property group
(ResourcesConfigAdapter)
3. move fhirVersion MIME-type parameter processing into a new JAX-RS
RequestFilter FHIRVersionRequestFilter and update tests accordingly
4. update FHIRPersistenceUtil.parseSystemHistoryParameters to take into
account the requested fhirVersion and scope the HistoryContext
appropriately
5. update SearchUtil.parseQueryParameters to take into account the
requested fhirVersion and scope the SearchContext appropriately
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
1. add the FHIRVersionParam to the OperationContext 2. use that with a ResourcesConfigAdapter to get the list of applicable resource types in EverythingOperation.getDefaultIncludedResourceTypes Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
mostly javadoc updates and a couple minor refactorings Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously I was only looking in the Accept header. Now, for PUT and POST requests, I'll check the Content-Type header first. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
punktilious
reviewed
Feb 4, 2022
|
|
||
| assertTrue(historyContext.getResourceTypes().isEmpty(), historyContext.getResourceTypes().toString()); | ||
| } finally { | ||
| FHIRRequestContext.get().setTenantId(originalTenantId); |
Collaborator
There was a problem hiding this comment.
Do you think we should use remove (or at least clear the tenantId here...all tests should be forced to establish their own tenant in the context, so I don't think setting the originalTenantId should be necessary (unless there's a specific use case I'm not thinking of here.)
Member
Author
There was a problem hiding this comment.
yes. i'm not sure how important it is, but i think calling FHIRRequestContext.remove() after each test is probably a good pattern to help prevent us from more errors related to the thread-local
In the latest draft of R4B, these resource types have a new choice type for the subject field. This means that all R4 instances will still be valid in R4B, but not vice-versa. Instead of coding up special support where R4 clients can PUT/POST these resource instances, but not read them, we chose to treat them like backwards-compatible resources and document the incompatibility concern for R4 clients. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
punktilious
reviewed
Feb 4, 2022
punktilious
reviewed
Feb 4, 2022
punktilious
reviewed
Feb 4, 2022
punktilious
reviewed
Feb 4, 2022
punktilious
approved these changes
Feb 4, 2022
Collaborator
punktilious
left a comment
punktilious
left a comment
There was a problem hiding this comment.
LGTM, just some minor comments
1. resolve TODO in Capabilities (replace getSupportedResourceTypes with ResourcesConfigAdapter) 2. fix stale javadoc for SearchUtil.useStoredCompartmentParam Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Member
Author
|
the latest runs failed due to an unrelated issue in our CI that has already been fixed in main, so I'm gonna go ahead and merge this into |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
and fhirVersion values ('4.0' and '4.3') in fhir-core (we had similar in fhir-model,
but those weren't available to fhir-config and the added complexity of the FHIR
model makes them a tad harder to work with)
fhir-server-config
fhirServer/resourcesproperty group(ResourcesConfigAdapter)
RequestFilter FHIRVersionRequestFilter and update the JAX-RS resources and
tests accordingly
account the requested fhirVersion and scope the HistoryContext
appropriately
requested fhirVersion and scope the SearchContext appropriately
resource types in EverythingOperation.getDefaultIncludedResourceTypes
also included the small removal for #3265