Supersedes HSEARCH-1852.
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.
This ticket is about #1. HSEARCH-3630 will address #2 later.
API-wise, we would allow users to provide some sort of "criteria", very much as described in HSEARCH-1852. Here is an example using the updated Search 6 API:
{code}
SearchResult<Book> result = searchSession.search( Book.class, Video.class )
.predicate( f -> f.match().onField( "title" )
.matching( "robot" ) )
.loading( o -> {
o. forType type ( Book.class ).stuff( /* configure stuff, such as association fetching */ );
// Use defaults for Video.class
} ))
.fetch();
{code}
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? |
|
