Supersedes HSEARCH-1852 Open . There was a FullTextQuery#setCriteriaQuery() in Search 5 that wasn't ported to Search 6, and we need to provide at least a similar level of functionnality, and if possible better. Several identified use cases for setCriteriaQuery so far:
- Setting loading options, such as forcing to load an association eagerly even though it's configured as lazy.
- Filter the hits of each "page" of the search results using WHERE clauses in the SQL query used to load the results. This is easy, but will potentially lead to empty pages before the end of the results if all the hits of that page were filtered out, even if it wasn't the last page.
- [new use case, not implemented in Search 5] Fully combine the results of a search query and a database query, avoiding any gap in the "pages" of the search results. This would be ideal, but it's close to impossible to implement efficiently except in some edge cases.
We should probably not try to address #3 for now: it will be rather complex to implement and test correctly, and very complex to optimize. API-wise, we would allow users to provide some sort of "criteria", very much as described in HSEARCH-1852 Open . Here is an example using the updated Search 6 API:
SearchResult<Book> result = searchSession.search( Book.class, Video.class )
.loading( Book.class, f -> )
.predicate( f -> f.match().onField( "title" )
.matching( "robot" ) )
.fetch();
Some caveats:
- Should the configuration apply exclusively to the referenced type, or to that type and every subtype?
- The fetch options could be implemented using the "fetch graph"/"load graph" feature from ORM, but I remember hearing from Steve himself that it had some serious limitations... Let's check that before we go that way. Maybe it was just the JPA APIs that were limited?
- Be careful of interactions with the cache lookup strategy introduced in HSEARCH-3349 In Progress . If the user defines WHERE clauses, the cache lookups must not be performed, because they could end up bypassing the WHERE clauses.
|