Inline table-source dependencies for SQLQuery operations - #385
Open
johngrimes wants to merge 7 commits into
Open
Inline table-source dependencies for SQLQuery operations#385johngrimes wants to merge 7 commits into
johngrimes wants to merge 7 commits into
Conversation
Add the acceptance-assertion script implementing the contract §4 invariants over the generated OperationDefinitions and pagecontent, and add the Table-Source Dependencies section to Common Operation Behavior defining the binding semantics shared by the two SQLQuery operations. Snapshot the pre-change ViewDefinition OperationDefinitions as the baseline for the no-change assertion.
Add the repeating dependency input parameter to the SQLQuery run operation, accepting inline ViewDefinition or SQLView table sources matched by url across the transitive dependency closure. Document the parameter, add an inline dependency-graph worked example, and enumerate the new 400 error cases on the run notes page.
Remove the three-part view parameter (name, viewReference, viewResource) from the SQLQuery export operation and add the flat repeating dependency parameter, identical to the run operation's. Rework the notes page: a dependency description linking to the shared semantics, a mixed stored/inline multi-query example, and the new 400 dependency error cases. Reword the intro and output documentation accordingly.
Rewrap the dependency description on the SQLQuery export notes page so no line begins with a dash, which kramdown was parsing as a list item and splitting the no-output-entries sentence into a stray bullet.
Use "materialized" in the Table-Source Dependencies section to match the prevailing spelling in the surrounding operation pages.
# Conflicts: # input/pagecontent/OperationDefinition-SQLQueryExport-notes.md
Renames the inline table-source parameter on $sqlquery-run and $sqlquery-export from dependency to view. The parameter carries a ViewDefinition or SQLView Library, so view names what is supplied rather than the relationship it satisfies, and it matches the name already used for the equivalent parameter on $viewdefinition-export and $materialize. Binding, precedence and error semantics are unchanged.
Collaborator
Author
|
@niquola I have renamed |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the three-part
viewparameter on$sqlquery-export(name,viewReference,viewResource) with a single flat repeatingviewparameter, and adds the identical parameter to$sqlquery-run, which had no equivalent. This proposes one shape for both operations, resolving #383 and #384.viewis aCanonicalResource(target profiles ViewDefinition and SQLView),0..*, at system, type and instance scope. Its binding semantics are defined once in a new "Table-Source Dependencies" section of Common Operation Behavior and linked from both notes pages: matching byurl(version-aware) across the transitive dependency closure, client-supplied precedence,400for a missing-url/unmatched/duplicate supplied resource, and the existing404for an unresolvable dependency. Both notes pages gain a worked example. The dropped parts are removed becauseviewReferenceduplicatedrelatedArtifact,namenamed nothing, and only ViewDefinitions could previously be supplied.The change introduces no new build errors or warnings and no
ignoreWarnings.txtadditions. The errors the build does report all concern unrelated ViewDefinition examples and the missing Jira spec artefact file, and none is attributable to the operations or pages touched here.If the working group approves, a follow-up issue will be raised on https://github.com/FHIR/sql-on-fhir.js to update the reference implementation and conformance tests.
Closes #383
Closes #384