sync with master#316
Merged
albertwang-ibm merged 29 commits intoAlbert-Master-Newfrom Oct 28, 2019
Merged
Conversation
Signed-off-by: John T.E. Timm <johntimm@us.ibm.com>
Signed-off-by: John T.E. Timm <johntimm@us.ibm.com>
1. Make AbstractWholeSystemSearchTest extend AbstractPLSearchTest and update the tests to verify the expected resource is actually returned from the search results (previously it only verified that we had some results). 2. Reduce log level for cases where we have a search parameter and either A. its not found in the extension-search-parameter-valuetypes.json config file or B. the extension-search-parameter-valuetypes.json config file isn't found at all for the tenant. Previously, I thought these were error conditions, but now I realize that 'A' is actually the most common path...whenever we get a search for a built-in search parameter we'll hit this clause. 3. Remove saved resources and reset the tenant after AbstractSortTest. Previously, this test set the tenant but never restored it afterwards. 4. Fix JDBCQueryBuilder to use the Instant that was created from the search parameter query value's DateTime (padded if needed). This means we need to convert it to a java.sql.Timestamp in order to bind it to the query since JDBC can't auto-convert from java.util.Instant for some reason. Additionally, I relaxed the generic type on SqlQueryData so that we can be more type-safe when adding bindVariables. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Added tests to AbstractSearchDateTest to cover ms precision on instant and dateTime data types. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
issue #305 - improve datetime processing in JDBCQueryBuilder
Now all date param values will be handled as an implicit range unless there are microseconds given. For example: * `01:01:01` -> `[01:01:01, 01:01:02)` * `01:01:01.111` -> `[01:01:01.111, 01:01:01.112)` * `01:01:01.111111` -> `01:01:01.111111` I considered guessing at the passed precision by looking for the last non-zero digit, but I decided just to handle it at the second / millisecond / microsecond level instead. Unless we start storing the original precision in the DateTime or move away from the use of DateTime for date search parameter values, we can't tell the difference between `01:01:01.1` and `01:01:01.100000`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
issue #309 - move task-api and task-core into database-utils
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
also removed references to virtual resources as able. needs more work but thats issue #2. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Signed-off-by: John T.E. Timm <johntimm@us.ibm.com>
Issue 285 - remove all traces of the user-provided schematron validation feature
… update Conformance.md In the previous commit, I tried [and failed] to treat fractional seconds like we do quantities and numbers (with explicit precision). This pull request backs off that a bit and finds a nice middle-ground where searches without fractional seconds are always handled like an implicit range, whereas all query parameters that include fractional seconds will be handled with "exact match" semantics and with arbitrary precision. Also updated Conformance.md to document this behavior. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
issue #305 - handle more date param values as ranges
FHIR Model Guide
1. introduce PagingTest (Abstract and JDBC) to verify PL paging behavior for both search and history interactions 2. re-introduce IncludeRevincludeTest (Abstract and JDBC) to verify _include/_revinclude behavior. we previously had AbstractQueryIncludeTest but we had commented it out in our transition to R4 and then I deleted it as part of pull request #279. this PR revives this old test and updates it to align with our new testing patterns. 3. added a single _revinclude test for each search parameter type to test the combination of search parameters and the _revinclude parameter 4. minor cleanup in FHIRResource to highlight potential issue if we have more resources than we can fit in Integer.MAX_VALUE (>2 billion) 5. minor doc updates to Conformance.md Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
1. formatted SQL in javadoc in both InclusionQuerySegmentAggregator
(added tags) and JDBCQueryBuilder (complete overhaul). we need to be
more careful when applying auto-formatting rules so that we don't break
this formatting again.
2. update InclusionQuerySegmentAggregator impl (and doc) to use IN
instead of `=` when building the WHERE clause for _revinclude searches.
Previous SQL:
```
WHERE P1.STR_VALUE='Patient/' ||
(SELECT LR.LOGICAL_ID FROM ...
```
New SQL:
```
WHERE P1.STR_VALUE IN
(SELECT 'Patient/' || LR.LOGICAL_ID FROM ...
```
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Issue 314 - improve PL test coverage and fix _revinclude issue
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
4 participants
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.
No description provided.