Issue #317 - Composite Search

[lmsurpre]

1. Converted JDBC DTO Parameter into a "proper" visitor pattern. This
   makes adding a CompositeParameter a lot easier and generally cleans
   things up a bit.

2. Introduced CompositParameter which contains a list of component
   parameters of any type.

3. Stubbed out Composite search tests, including:

   • extension-search-parameters.json with a single composite search parm
   • BasicComposite.json with a repeating element for testing composite
   • AbstractSearchCompositeTest stub for laying out the test logic
   • JDBCSearchCompositeTest for executing the tests on Derby

4. SearchUtil and ParametersUtil updates to include SearchParameter
   canonical uris as an alternative key to the SearchParameter code

   • Also updated fhir-search tests to double the expected search
     parameter counts accordingly

5. Implemented initial CompositeParameter extraction logic in
   FHIRPersistenceJDBCImpl; needs further cleanup

6. Introduce support for db-generated identity columns in
   fhir-database-utils. Instead of adding to columndefinition, I added it
   to Table...similar to how primaryKey was implemented.

7. Added ROW_ID columns for all X_Y_VALUES tables and set to GENERATED BY DEFAULT and made primary key to ensure uniqueness.

8. Created X_COMPOSITES table with foreign keys to the X_Y_VALUES
   ROW_IDs. Also renamed FhirResourceGroup to FhirResourceTableGroup to
   better reflect its purpose.

9. Added visit(CompositeParmVal) variant to
   ExtractedParameterValueVisitor and implemented initial DTO logic in
   ParameterVisitorBatchDAO; now the components are saved to the X_Y_VALUES
   tables and the composite row is written using their generated ROW_IDs
   (obtained from preparedStatement.getGeneratedKeys())

10. Updated SearchUtil to parse composite parameters, both for regular and chained searches

11. Added processComposite method to AbstractQueryBuilder and JDBCQueryBuilder:

    • where clause gets generated in processCompositeParm
    • for "normal" requests, the query segment gets manipulated by QuerySegmentAggregator
    • for "chained" requests, the query segment is manipulated from JDBCQueryBuilder.appendInnerSelect

12. Expanded Composite search tests (and fixed related issues):

• at least one test for each search parameter table type we support (except Location)
• chained searches (where the composite parameter is at the end of a reference chain)
• support for the missing modifier on composite parameters
• 'or' behavior (e.g. val1$val2,val1$val3)

13. Updated Db2 stored proc to remove composite parameters. Also removed the outdated addParameterArrayTypes.sql stored proc and the associated array types which were still in our schema but no longer used.

14. Addressed issue Db2 deadlock while executing com.ibm.fhir.schema.app.Main --update-schema #508 by adding a dependency from the resource tables to the global parameter value tables...now the global parameter value tables should always be added first and this should hopefully avoid the deadlock.

Signed-off-by: Lee Surprenant lmsurpre@us.ibm.com

[JohnTimm]

LGTM

[prb112]

* 2, has a particular purpose. Can we throw this in a Constant that explains it?
SearchTest.NUMBER_2_DOES_X?

[lmsurpre]

Because we're now indexin the list by both the code and the canonical uri, the expected size is now 2 times the number of search parameters.
I don't even love these tests which just happen to know the number of expected parameters in the file...seems like it would be better to just compute it from the file...otherwise its for sure gonna break each time we add or remove a search parameter.

[prb112]

LGTM, needs to be updated master (obvious as it is in progress)

[prb112]

LGTM