How firely sdk handle extra fields (not extension) in Poco and ISourc…

…eNode
jackliusr · Jul 23, 2024 · 6b186a0 · 6b186a0
1 parent 8b6fdee
commit 6b186a0
Showing 1 changed file with 13 additions and 0 deletions.
diff --git a/content/posts/2024/07/fhir-expando.adoc b/content/posts/2024/07/fhir-expando.adoc
@@ -0,0 +1,13 @@
+---
+title: How firely sdk handle extra fields (not extension) in Poco and ISourceNode
+date: 2024-07-23T10:10:00+08:00
+categories:
+- tech
+tags:
+- Fhir
+- Firely
+---
+
+Most time, I think json is forward and backward compatible as long as some convention is kept such as adding fields only etc. I always thought so since I studied CQRS and event sourcing. Is it true for FHIR, especially firely sdk? I answered so in a discussion, however I doubted it as I didn't do it in FHIR. Here I have a short code to demostrate the two case. In the end, the result is yes and no. For poco case, firely sdk will raise an exception; on the contrast, ISourceNode can parse the data successfully. It will fail when calling ToPoco from ISourceNode as well. Now there is one open question how do we persist data ? via POCO or ISourceCode? Do we allow those extra fields?
+
+{{< gist jackliusr ae8aa63d678dc764ea701dc2a8a1c3bb >}}