Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
OOM during FHIR XML schema inspection
See original GitHub issueI fixed #573 and then hit OOM…
It loaded 9,075,113 fields and died. A bit surprising that 9 millions of fields could be loaded as a AtlasMap Document model.
So definitely loading whole FHIR schema is unrealistic. Browser would crash even with thousands of fields. Nobody like to scroll hundreds of fields in AtlasMap UI and map one by one.
How can we slim it down to realistic number of fields? Is it even possible? We would need some “filtering” on inspection, as well as deeper understanding of FHIR object model and real usecases to figure out how to screw this gigantic object in to AtlasMap UI.
Issue Analytics
- State:
- Created 5 years ago
- Comments:21 (15 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
We create DataShapes for custom API client connectors from JSON schema and generate XML schema if the format for the API call is XML. For example here is how we do it for HTTP request shape:
https://github.com/syndesisio/syndesis/blob/0fc334e6d29b5bae40856251728c4ab7c82d6943/app/server/api-generator/src/main/java/io/syndesis/server/api/generator/swagger/UnifiedXmlDataShapeGenerator.java#L82
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!