Open brianpos opened 2 months ago
The philosophical question is: "is a renamed property still the same property".
Another point to consider: when we add support for having unknown properties in resources (added to a dictionary, but not available via a code-generated property) in preparation of R6 ("allow unknown elements"), having properties that do not exist in that version's metadata will become more common.
No answers here, just a braindump of stuff to consider.
Decided that this for now is one property with two names:
Add:
[FhirElement("content", Order=70, Since = FhirRelease.STU3)]
[FhirElement("data", Order=70, Since = FhirRelease.R4)]
On ContentElement
.
The problem that remains is having to fix ITypedElementOnPoco
. And probably others.
Also check if the cardinality validator fetches the correct name when throwing errors.
Let's try and see what happens. Add [Obsolete] to the Content property.
Describe the bug When serializing a Binary resource to XML a Null reference is thrown. This is due to the children() function returning all the children without considering the version of fhir being processed.
Data
andContent
hold the same data, but are apprpriate in different versions, and the ReadBinaryFataFromMessage in the HttpContentParsers sets both. https://github.com/FirelyTeam/firely-net-sdk/blob/963660e981550356d5535dad538aebec5e25e1da/src/Hl7.Fhir.Base/Rest/HttpContentParsers.cs#L203Hence when hit in the PocoElementNode constructor the element definition for one of them isn't found and crashes.
Note: Create does not do this... as it doesn't detect that the resource type was for a Binary! (so create is done using the resource format rather than a binary stream)
To Reproduce Steps to reproduce the behavior:
Use this unit test to check that the serialization doesn't throw the issue, but would be preferable if the update functionality doesn't set both fields
Better to udpate
TestCreatingBinaryResourceHttpClient
to also check the fields are appropriateExpected behavior Unit test should pass, and XML is created correctly.
Version used:
Additional context The only workaround is to request the resource response format in the client settings. clientFhir.Settings.BinaryReceivePreference = BinaryTransferBehaviour.UseResource;