FHIR Chat · Data type not supported for SearchParameter X · ibm

Stream: ibm

Topic: Data type not supported for SearchParameter X

Lee Surprenant (Nov 04 2019 at 14:40):

In https://github.com/IBM/FHIR/pull/351 I added some validation to the search parameter value extraction process. I thought it might break things, but all our tests are still passing. However, now our R4ExamplesDriver is littered with INFO messages similar to these:

Nov 04, 2019 9:28:42 AM com.ibm.fhir.persistence.jdbc.impl.FHIRPersistenceJDBCImpl extractSearchParameters
INFO: Skipping search parameter 'context-quantity'  with id '{
    "id": "conformance-context-quantity"
}' for resource type CapabilityStatement
java.lang.IllegalArgumentException: Data type 'CodeableConcept' is not supported for SearchParameter 'context-quantity' of type 'quantity'
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.invalidComboException(JDBCParameterBuildingVisitor.java:587)
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.visit(JDBCParameterBuildingVisitor.java:288)

Nov 04, 2019 9:28:44 AM com.ibm.fhir.persistence.jdbc.impl.FHIRPersistenceJDBCImpl extractSearchParameters
INFO: Skipping search parameter 'onset-age'  with id '{
    "id": "Condition-onset-age"
}' for resource type Condition
java.lang.IllegalArgumentException: Data type 'DateTime' is not supported for SearchParameter 'onset-age' of type 'quantity'
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.invalidComboException(JDBCParameterBuildingVisitor.java:587)
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.visit(JDBCParameterBuildingVisitor.java:153)

Nov 04, 2019 9:33:31 AM com.ibm.fhir.persistence.jdbc.impl.FHIRPersistenceJDBCImpl extractSearchParameters
INFO: Skipping search parameter 'context'  with id '{
    "id": "conformance-context"
}' for resource type StructureMap
java.lang.IllegalArgumentException: Data type 'Reference' is not supported for SearchParameter 'context' of type 'token'
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.invalidComboException(JDBCParameterBuildingVisitor.java:587)
    at com.ibm.fhir.persistence.jdbc.util.JDBCParameterBuildingVisitor.visit(JDBCParameterBuildingVisitor.java:487)

Lee Surprenant (Nov 04 2019 at 14:42):

I'm gonna look into this a bit to see why we have so many search parameter expressions that lead to values of the wrong type

Paul Bastide (Nov 04 2019 at 14:44):

could it be the example?

Lee Surprenant (Nov 04 2019 at 14:45):

my initial guess is that its our handling of choice elements

Lee Surprenant (Nov 04 2019 at 14:45):

Condition.onset.as(Age) | Condition.onset.as(Range)

Lee Surprenant (Nov 04 2019 at 14:46):

thats the expression for Condition-onset-age

Lee Surprenant (Nov 04 2019 at 14:46):

but the element is allowed to be of other types

Lee Surprenant (Nov 04 2019 at 14:46):

pasted image

Lee Surprenant (Nov 04 2019 at 14:46):

@John Timm should as be returning an empty list when the type doesn't match?

John Timm (Nov 04 2019 at 15:01):

If the left operand is a collection with a single item and the second operand is an identifier, this function returns the value of the left operand if it is of the type specified in the second operand, or a subclass thereof. If the identifier cannot be resolved to a valid type identifier, the evaluator will throw an error. If there is more than one item in the input collection, the evaluator will throw an error. Otherwise, this operator returns the empty collection.

John Timm (Nov 04 2019 at 15:02):

These are the semantics of the as operator. AFAIK, the as function works the same way.

Lee Surprenant (Nov 04 2019 at 15:03):

ok, so Condition.onset should be a single element in this case

Lee Surprenant (Nov 04 2019 at 15:03):

help me parse:

If the identifier cannot be resolved to a valid type identifier, the evaluator will throw an error.

Lee Surprenant (Nov 04 2019 at 15:04):

i guess thats specifically about the argument being passed (e.g. Age)

John Timm (Nov 04 2019 at 15:04):

yep, exactly

Lee Surprenant (Nov 04 2019 at 15:04):

and Age should be a valid identifier, so I think I'm right to expect that this should be returning an empty list

John Timm (Nov 04 2019 at 15:05):

yes, i agree. i think empty collection is what we would expect

Lee Surprenant (Nov 04 2019 at 15:08):

our fhirpath unit tests are pretty deep. do we have a simple "create fhir resource and select something with fhirpath" example?

Lee Surprenant (Nov 04 2019 at 15:12):

i guess its just

    @Test
    void testSelectAs() throws Exception {
        Resource resource = TestUtil.readExampleResource("json/ibm/complete-mock/Patient-1.json");
        FHIRPathEvaluator evaluator = FHIRPathEvaluator.evaluator();
        evaluator.evaluate(resource, fhirpath);
    }

any need for EvaluationContext?

Paul Bastide (Nov 04 2019 at 15:13):

yes, interesting so... we run through extractParameterValues

Paul Bastide (Nov 04 2019 at 15:13):

if it's in the fhir-examples, we run through the correlated expressions, if as is one of them, we run through it

John Timm (Nov 04 2019 at 15:16):

EvaluationContext would be used if / when you want to reuse the same FHIRPath tree and improve performance. The signature without EvaluationContext creates a new one every time.

Lee Surprenant (Nov 04 2019 at 15:17):

ok, makes sense

Lee Surprenant (Nov 04 2019 at 15:17):

some javadoc to that effect would go long way :-)

Lee Surprenant (Nov 04 2019 at 15:17):

anyway, i confirmed the issue

Lee Surprenant (Nov 04 2019 at 15:17):

    @Test
    void testSelectAs() throws Exception {
        Resource resource = TestUtil.readExampleResource("json/ibm/complete-mock/Patient-1.json");
        FHIRPathEvaluator evaluator = FHIRPathEvaluator.evaluator();

        Collection<FHIRPathNode> result = evaluator.evaluate(resource, "Patient.deceased as dateTime");
        assertEquals(result.size(), 1, "Number of selected nodes");
    }

John Timm (Nov 04 2019 at 15:18):

I thought all of the FHIRPathEvaluator public methods already had Javadoc

Lee Surprenant (Nov 04 2019 at 15:18):

not in master

Lee Surprenant (Nov 04 2019 at 15:18):

pasted image

John Timm (Nov 04 2019 at 15:18):

guess not

John Timm (Nov 04 2019 at 15:18):

weird

Lee Surprenant (Nov 04 2019 at 15:19):

anywya, i'll open a new issue for this one (the asissue, not the missing javadoc)

Lee Surprenant (Nov 04 2019 at 15:30):

https://github.com/IBM/FHIR/issues/355

Lee Surprenant (Nov 05 2019 at 13:21):

ok, john and i tag-teamed this one and its now addressed

Lee Surprenant (Nov 05 2019 at 13:23):

however, we still see the message showing up in a few places. i traced these down to:

1. issues with the spec (see https://chat.fhir.org/#narrow/stream/179166-implementers/topic/data.20type.20vs.20search.20parameter.20type/near/179929756); and
2. issues with our JDBCSearch tests (where I was purposefully mismatching data types and search parameter types to see what would happen)

Lee Surprenant (Nov 05 2019 at 13:23):

for #2, we should probably just move those tests into the ParameterExtractionTest since it will be easier to verify an IllegalArgumentException from there

Lee Surprenant (Nov 07 2019 at 21:11):

#2 has been addressed simply by removing the unnecessary data elements from the Basic examples; now we should only see these for the bad spec searchparameters

Last updated: Apr 12 2022 at 19:14 UTC