Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixing fulltext search wit h_lastUpdated filter #6411

Open
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

TipzCM
Copy link
Collaborator

@TipzCM TipzCM commented Oct 28, 2024

closes #6404

tadgh and others added 2 commits October 26, 2024 01:09
* Contained bug

* more tests

* changelog, tests, implementation

* code review

* backwards logic
Copy link

github-actions bot commented Oct 28, 2024

Formatting check succeeded!

@TipzCM TipzCM enabled auto-merge (squash) October 30, 2024 17:12
# Fulltext Search with _lastUpdated Filter

Fulltext searches have been updated to support `_lastUpdated` search parameter. A reindexing of Search Parameters
is required to migrate old data to support the `_lastUpdated` search parameter.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be expanded to clarify under what exact conditions it would be necessary to do this, since requiring a reindex of all of your data is a huge ask.. Presumably this only matters if XXX is set to YYY and you are intending to perform a search containing ZZZ

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's kinda required if you're using lucene/fulltext search at all.

Currently, any searches with _lastIndex will not use lucene (if that's the only parameter).

If _lastIndex is provided with any other parameter, it will not work.

This includes in our $mdm-clear job (which was the original bug reported)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this require explicitly configuring AdvancedHSearchIndexing (which is disabled by default) in order for it to try using lucene to satisfy that query? If it's going to lucene even with that setting disabled, we should fix that bug too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is only required if they are already using lucene. Which is why i included the migration note.

If they aren't using lucene/fulltext search, then obviously they won't have to migrate data to fill lucene data in. It doesn't exist.

Copy link
Collaborator

@jamesagnew jamesagnew Nov 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No but does this happen to anyone who has lucene enabled, or do they specifically need to have the AdvancedHSearchIndexing feature enabled (again, a feature which is disabled by default)? Please test this if you aren't sure. That flag is the thing that determines whether we use lucene for parameters other than _text and _content. Most people will have it disabled, and if we're using lucene to handle _lastUpdated even with that flag disabled, then that in itself is probably a bug.

Please remember, you are asking people with potentially a lot of data to perform what would be an expensive and lengthy reindex. You need to be very specific about what circumstances would lead to someone needing to do this.

if (myFulltextSearchSvc != null && !myFulltextSearchSvc.isDisabled()) {
if (myFulltextSearchSvc != null && !myFulltextSearchSvc.isDisabled() && changed.isChanged()) {
// set the lastUpdated dates so we can use them to search in lucene
theResource.getMeta().setLastUpdated(theTransactionDetails.getTransactionDate());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a super weird thing to be doing here. Why is it necessary to modify the resource passed in? We index the entity, not the FHIR resource model class.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fields to index are determined by what's in the resource (not the entity) since the resource contains the changed fields.

ExtendedHSearchIndexExtractor is where we create the ExtendedHSearchIndexData and SearchParamTextPropertyBinder is what consumes it to wrie the indexes

mrdnctrk and others added 9 commits October 31, 2024 12:03
…or $validate-code operation. (#6438)

* Move the validation providers to the test utilities package such that they can be reused.

* Update IValidationSupport.CodeValidationIssue structure such that it meets the FHIR specification. Update RemoteTerminologyServiceValidationSupport and VersionSpecificWorkerContextWrapper translation for issues.

* New tests for issue translation. Move test class to a different package so that we can add another test class.

* Some simplification in the issue API to simplify building of issues.

* Fix compilation errors.

* Update providers to allow multiple responses and add  support for the fetchCodeSystem call through method find.

* Setup the first test for resource validation with remote terminology providers.

* Fix NullPointerException

* avoid calling validateCode for CodeSystem where system is null

* Keep old public API methods (and class name) in IValidationSupport and mark them as deprecated to avoid breaking dependencies.

* Revert local change to debug for duplicate errors.

* Add more test cases for resource validation. Throw exception to signal missing test setup to make it obvious.

* Simplify test setup.

* Add some more javadoc

* Add javadoc for the new test class

* Add more tests

* Address code review comments in IValidationSupport.

* Add changelog
Change Map to Multimap to support multiple and clauses.
…RAGE_PRECHECK_FOR_CACHED_SEARCH (#6436)

* fix interceptor hooks from requestDetails not getting called for STORAGE_PRECHECK_FOR_CACHED_SEARCH

* added unit tests and updated changelog

* added one more test case
Lightweight implementation of the adapter pattern.
<!-- <logger name="tracer" level="TRACE" additivity="false">-->
<!-- <appender-ref ref="STDOUT" />-->
<!-- </logger>-->
<logger name="org.hibernate.search.elasticsearch.request" additivity="false" level="trace">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be switched back off before merging.

@@ -31,15 +31,15 @@
<logger name="ca.uhn.fhir.jpa.bulk" level="info"/>

<!-- more debugging -->
<!--
<!-- &lt;!&ndash;-->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be switched back off before merging

Copy link

codecov bot commented Nov 7, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (rel_7_6@7faf0f7). Learn more about missing BASE report.

Additional details and impacted files
@@            Coverage Diff             @@
##             rel_7_6    #6411   +/-   ##
==========================================
  Coverage           ?   83.54%           
  Complexity         ?    27781           
==========================================
  Files              ?     1741           
  Lines              ?   107563           
  Branches           ?    13507           
==========================================
  Hits               ?    89859           
  Misses             ?    11917           
  Partials           ?     5787           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@TipzCM TipzCM changed the base branch from rel_7_6 to master November 8, 2024 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants