-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start support for PATCH verb. #341
Conversation
Can someone tell me what is the secret for the integration tests? I have left them unchanged and still they fail :-( |
@jjrdk will have to look into it |
src/Spark.Engine/Service/FhirServiceExtensions/IPatchApplicationService.cs
Outdated
Show resolved
Hide resolved
src/Spark.Engine/Service/FhirServiceExtensions/PatchApplicationService.cs
Outdated
Show resolved
Hide resolved
src/Spark.Engine/Service/FhirServiceExtensions/PatchApplicationService.cs
Outdated
Show resolved
Hide resolved
src/Spark.Engine/Service/FhirServiceExtensions/PatchApplicationService.cs
Outdated
Show resolved
Hide resolved
Appreciate the effort @jjrdk! |
@jjrdk been looking some more into this and doing some tests. Trying to run a PATCH via Postman using the Parameters resource below throws the exception: Did you consider using FhirPath in place of Linq Expressions? For some of the operations I think this could simplify things You are maybe already aware that the ToPatch extension method generates delete operations if the property is null. I kind of get why, but this could also be a bit dangerous behavior. So if we in the future going to use this in a client-side manner we would need to be aware of this. In such a scenario we might not always have the full resource And lastly not sure why the integration tests currently fails, but I have run them locally and they run fine.
|
@kennethmyhra Thanks for getting back on this. I had a look at your test case, and the problem is that the value is parsed by the FHIR parser as a Code (Hl7.Fhir.Model.Code) when the expected value is Code (Hl7.Fhir.Model.Code). These values are unrelated in the type hierarchy, so casting is not an option. I'll have a closer look at the case before proposing a solution. I'd like to avoid hacking in too many custom conversions. Regarding FhirPath or LINQ expression, then I actually use the official FhirPath compiler to get the path and then transform this using a visitor. I can have a look at whether it works better to have a visitor that directly updates the resource based on the FhirPath. On the last point, then I agree that there are going to be a lot of scenarios that have to be considered in terms of access rights and generating patches. I see three ways to approach this:
Maybe a mix of 2 and 3 is preferred. |
I had a look at the handling of Code and it's the only generic subtype of DataType, so I implemented a special case for that. I added tests for other common types. |
@jjrdk Will pull this, just need to have another look at why the integration tests fail |
@kennethmyhra Before you pull, let me try to see if the issue is the test data files. I'll try to pull the test data into code and see if I can somehow get this issue fixed. Would not like to provide broken integration tests. |
Seems like that worked @jjrdk. That's strange, shouldn't really have had an impact and was not all what the integrations tests complained about. |
I'll try to bring them back individually and see if I can pinpoint the offender. |
Yep, I'll leave the PR until you have done some more investigation |
@jjrdk The guy who set up the integration tests will have a look at why those are failing for this PR. Any other suggestion I have is to revert the last 4 commits that made this fail again or pull out the diff of the changes you want to apply and create a new PR and see if that still fails. |
If this may help.. from the html summaries archive:
|
Problematic records:
|
Sorry can't tell you more for now, will be able to check it further on the next week, traveling currently. For now, you could try to run integration tests locally, using the fresh Mongo db and web instance, running via Docker, just as in the Integration Tests workflow setup here, in this repo. Try running it on the web instance with- and without changes, apply some of them, run again etc. If you can of course. |
@andy-a-o Thanks for the investigation. I had found the error message with mis-ordered items in the test errors, but had not dug further. Will take a closer look. |
24df46f
to
3c5639c
Compare
I tried reverting the latest commits, but that doesn't seem to help :-( |
I think currently we can rule out that there is anything wrong with this PR. Andy and me will have to investigate the integration tests further |
Again thanks @jjrdk, much appreciated! |
I started this work to add support for patch operations as described in the FHIR specs.
This is just an initial draft to get the work started, so any feedback regarding how it should be properly fit into the architecture would be appreciated. Specifically there are some open points about how to integrate with the IAsyncFhirService.
Currently there is support for FHIR patches using Parameters. No json/xml patch is currently supported.
For the different patch operations, there are test cases for different examples, but additional test cases would help make this feature more robust.