When authoring SQL on FHIR SQLView and SQLQuery Library resources, it would be very helpful to attach the SQL from a separate file using the existing ig-loader- mechanism, the same way CQL content IGs attach .cql files. That keeps the SQL editable and reviewable as a plain file rather than hand-encoded base64 in the resource.
At the moment this does not quite work for SQL. AdjunctFileLoader.determineContentType() recognises pdf, dicom, png, gif, jpeg, cql, feature, json, xml, text and txt, but not sql, so it returns null and content.contentType is never set. The SQL on FHIR SQLView/SQLQuery profiles require content.contentType to be present and to start with application/sql (their sql-must-be-sql-expressions invariant), so a loaded .sql attachment fails validation. And because checkReplaceable() only fires when the attachment has no contentType preset, it is not possible to set application/sql by hand and still use the loader.
Would you consider adding a mapping from the sql extension to application/sql in determineContentType()? That single addition would let SQLView and SQLQuery Libraries reference their SQL via content.id = ig-loader-<file>.sql and have the publisher base64-encode it with the correct content type, mirroring the CQL workflow and avoiding hand-maintained base64.
Reference: org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools/publisher/loaders/AdjunctFileLoader.java, method determineContentType().
When authoring SQL on FHIR SQLView and SQLQuery
Libraryresources, it would be very helpful to attach the SQL from a separate file using the existingig-loader-mechanism, the same way CQL content IGs attach.cqlfiles. That keeps the SQL editable and reviewable as a plain file rather than hand-encoded base64 in the resource.At the moment this does not quite work for SQL.
AdjunctFileLoader.determineContentType()recognisespdf,dicom,png,gif,jpeg,cql,feature,json,xml,textandtxt, but notsql, so it returnsnullandcontent.contentTypeis never set. The SQL on FHIR SQLView/SQLQuery profiles requirecontent.contentTypeto be present and to start withapplication/sql(theirsql-must-be-sql-expressionsinvariant), so a loaded.sqlattachment fails validation. And becausecheckReplaceable()only fires when the attachment has nocontentTypepreset, it is not possible to setapplication/sqlby hand and still use the loader.Would you consider adding a mapping from the
sqlextension toapplication/sqlindetermineContentType()? That single addition would let SQLView and SQLQuery Libraries reference their SQL viacontent.id = ig-loader-<file>.sqland have the publisher base64-encode it with the correct content type, mirroring the CQL workflow and avoiding hand-maintained base64.Reference:
org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools/publisher/loaders/AdjunctFileLoader.java, methoddetermineContentType().