Open dennisverspuij opened 2 years ago
Yes, we agree that the configuration of the index prefix should be flexible and not "hard coded".
Fully agree!
@tadgh is it still valid? Check my other ticket. Otherwise we should close it to reduce confusion.
Ah I see what you mean.
Internally, we have moved to a hibernate-search based implementation for lastN, (relying on the existing fulltext resroucetable-* index) which means that the existing functionality for index prefixing should be supported on lastN. The code path involving ElasticsearchSvcImpl is obsolete now, and will be removed in a subsequent release.
To use the hibernate-search solution, you have to enable "advanced hibernate search indexing". All the ES-specific stuff is slated for removal soon. If you absolutely need this immediately, we will happily accept a PR against the existing elasticsearchsvcimpl.
Is that true, I thought the use of Elastic Search was introduced as better replacement for Lucene? Currently advanced hibernate search indexing enabled is using either backend. I have never seen any announcement of removal of need of such search backend.
There are now two back-ends for the $lastn operation:
The Hibernate Search implementation is available when advanced_lucene_indexing
is true. It uses the defined prefix for the resource_XXXXXX
indices. You can ignore the Legacy Elasticsearch implementation. It is deprecated and to be removed.
@michaelabuckley I enabled advanced_lucene_indexing, using OpenSearch and removing the bean from ElasticSearchConfig.java. However, the server tells me that lastn is not available.
here is my config: https://pastebin.com/5ABNbj3N
{ "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "processing", "diagnostics": "HAPI-2033: LastN operation is not enabled on this service, can not process this request" } ] }
Merge request #2963 allows for prefixing ElasticSearch indexes resourcetable and termconcept, but ca.uhn.fhir.jpa.search.lastn.ElasticsearchSvcImpl forgets to prefix the lastn code_index and observation_index indexes as well. Would be great if that can be fixed so multiple Hapi servers could use same ElasticSearch instance. Furthermore if would be nice if the prefix could be set through application.yml. Thanks!