We're updating the issue view to help you get more done. 

Per-type, finer loading options in search queries (fetch graph, ...)

Description

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:

  1. Setting loading options, such as forcing to load an association eagerly even though it's configured as lazy.

  2. 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. 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:

1 2 3 4 5 6 SearchResult<Book> result = searchSession.search( Book.class, Video.class ) .loading( Book.class, f -> /* configure stuff, such as association fetching */ ) // Use defaults for Video.class .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?

Environment

None

Status

Assignee

Unassigned

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Fix versions

Priority

Major