question-mark
Stuck on an issue?

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.

Use of Retrieve and Query in a Parameter

See original GitHub issue

The expression.xsd file describes a ParameterDef as taking a possible default attribute, which is defined as an arbitrary expression. Things like

parameter IntParameter default 0
parameter DateTimeParameter default DateTime(2018, 1, 1, 0, 0, 0)

make enough sense, but the spec doesn’t seem to imply that a query or retrieve wouldn’t be acceptable. At least, they seem permissible to the compiler:

library Query version '1'

using FHIR version '3.0.0'

include FHIRHelpers called FHIRHelpers

parameter RetrieveParameter default [Condition]
parameter QueryParameter List<FHIR.Condition> default ([Condition] C where C.clinicalStatus = 'active')

context Patient

define GetRetrieveParameter: RetrieveParameter
define GetQueryParameter: QueryParameter

RetrieveParameter appears to compile without any warning. QueryParameter however, throws “Internal translator error” annotations starting at the default value, but still seems to compile into an AST just fine. Interestingly, if the type is removed from QueryParameter, the query still compiles as well as if it was there, but another “semantic” annotation error is thrown saying that the compiler “Could not determine parameter type for parameter QueryParameter”, which seems anomalous since the AST appears to have gotten all the correct type information in the node resultTypeSpecifiers.

The big question is that since parameters have no notion of their Context, (assuming a Retrieve in a parameter is acceptable) it would seem we would only know whether it should pull all resources for one patient, or for all patients based on where the parameter is accessed. I suppose this would mean a single parameter could have two different meanings depending not on the way the value expression is declared, but depending on where that value expression is evaluated.

Since it also seems that parameters can reference previously defined parameters in their default values, this would seem to imply parameters would have to lazily evaluate, since their values in some instances are dependent on the calling context.

What are some of the expected semantics of Retrieves and Queries in parameter default values, and how should those expected to be evaluated against differing Contexts?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
bdrillardcommented, Mar 2, 2018

Thanks for the response @cmoesel. I can’t personally think of a case where using a retrieve in a default value expression would be necessary, or at least any more desirable than the approach you lay out. My main concern was whether an implementation would have to support such expressions. If we don’t have to, then as you say, it’ll remove a major implementation concern.

If @brynrhodes confirms your assumption, it might help to log a clarifying issue to STU that requests updated doc stating parameters’ default values can only be constructed from static values, or to perhaps even to log an issue to the CQL-to-ELM compiler that explicitly rejects retrieve in a parameter (just a suggestion on that one though, open to more discussion).

2reactions
cmoeselcommented, Mar 3, 2018

That’s a great question, and a great analysis of the implications of having retrieves as default parameter values. @brynrhodes should confirm, but I don’t think we ever intended for retrieves to be used as default values. While the specification is not clear about this, I think that default parameter values are intended to be static values, with perhaps the exception of the system functions: Today() and Now().

Is there a strong use case for using a retrieve as a default value? As you noted, supporting such a thing would introduce significant implementation burden. I believe that you could accomplish the same thing via other means. For example, see below for an alternate approach to accomplishing what you described above:

library Query version '1'

using FHIR version '3.0.0'

include FHIRHelpers version '3.0.0' called FHIRHelpers

parameter RetrieveParameter List<FHIR.Condition> default null
parameter QueryParameter List<FHIR.Condition> default null

context Patient

define GetRetrieveParameter:
  if RetrieveParameter is not null then RetrieveParameter
  else [Condition]

define GetQueryParameter:
  if QueryParameter is not null then QueryParameter
  else [Condition] C where C.clinicalStatus = 'active'

This approach works today (I was able to successfully compile it without errors).

Read more comments on GitHub >

github_iconTop Results From Across the Web

Use parameters in queries, forms, and reports
This article explains how to use forms in Access to enhance your use of parameters in queries, forms, and reports.
Read more >
How to retrieve custom headers, query and URI parameters ...
You can capture a URI parameter (also known as a Path Param) using DataWeave. A URI parameter identifies a specific resource whereas a...
Read more >
Retrieve Query Parameters from HTTP URL - Mulesy.com
Tutorial to provide step by step configuration required to read different query parameters from the HTTP request. Retrieve Query Parameters from HTTP URL....
Read more >
Can use a parameter in Retrieve from or write to database ...
I get a sql statement value into a parameter ${querystatement} and try to query to database. But i got a error the result...
Read more >
How do I retrieve query parameters in a Spring Boot controller?
Use @RequestParam @RequestMapping(value="user", method = RequestMethod.GET) public @ResponseBody Item getItem(@RequestParam("data") String ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found