In input/fsh/operations.fsh, the filtering parameters differ between each run operation and its export counterpart, in two different ways:
| Operation |
patient |
group |
$viewdefinition-run |
0..1 |
0..* |
$viewdefinition-export |
0..* |
0..* |
$sqlquery-run |
absent |
absent |
$sqlquery-export |
0..* |
0..* |
$viewdefinition-run caps patient at one, while its export counterpart repeats it. Since group is 0..* on both, a client can already select a multi-patient cohort on run by passing several groups, so the cap doesn't bound the size of the result. It just makes the obvious way of naming two patients unavailable and pushes the client towards creating a Group instead.
$sqlquery-run has no patient or group at all, while $sqlquery-export has both, with a good deal of care taken over their semantics in the notes page. The FSH carries the comment // Input parameters — filtering (from $viewdefinition-export) against the export block, which reads like the parameters were brought across when $sqlquery-export was added and not applied to run at the same time. Filtering looks implementable for run, since it amounts to the same thing the export operation already does before materialising the dependency views.
The practical cost is that moving a query from synchronous to asynchronous execution ought to be a matter of switching operation, but the filtering contract changes underneath. Patient-handling code can't be shared, and clients need to know which operation they're calling before they know how they may scope the request.
Were either of these deliberate? If the intent was to bound the cost of a synchronous request, _limit and server-side limits seem like a better fit, given group already leaves the cost unbounded on $viewdefinition-run. Otherwise, relaxing $viewdefinition-run to 0..* and adding patient and group to $sqlquery-run would bring the four operations into line.
Happy to raise a PR if there's agreement on the direction, and equally happy to split the $sqlquery-run half out if that's easier to progress separately.
In
input/fsh/operations.fsh, the filtering parameters differ between each run operation and its export counterpart, in two different ways:patientgroup$viewdefinition-run$viewdefinition-export$sqlquery-run$sqlquery-export$viewdefinition-runcapspatientat one, while its export counterpart repeats it. Sincegroupis 0..* on both, a client can already select a multi-patient cohort on run by passing several groups, so the cap doesn't bound the size of the result. It just makes the obvious way of naming two patients unavailable and pushes the client towards creating a Group instead.$sqlquery-runhas nopatientorgroupat all, while$sqlquery-exporthas both, with a good deal of care taken over their semantics in the notes page. The FSH carries the comment// Input parameters — filtering (from $viewdefinition-export)against the export block, which reads like the parameters were brought across when$sqlquery-exportwas added and not applied to run at the same time. Filtering looks implementable for run, since it amounts to the same thing the export operation already does before materialising the dependency views.The practical cost is that moving a query from synchronous to asynchronous execution ought to be a matter of switching operation, but the filtering contract changes underneath. Patient-handling code can't be shared, and clients need to know which operation they're calling before they know how they may scope the request.
Were either of these deliberate? If the intent was to bound the cost of a synchronous request,
_limitand server-side limits seem like a better fit, givengroupalready leaves the cost unbounded on$viewdefinition-run. Otherwise, relaxing$viewdefinition-runto 0..* and addingpatientandgroupto$sqlquery-runwould bring the four operations into line.Happy to raise a PR if there's agreement on the direction, and equally happy to split the
$sqlquery-runhalf out if that's easier to progress separately.