Skip to content

Conversation

@BartChris
Copy link
Collaborator

@BartChris BartChris commented Oct 13, 2025

One of the problems with the current Hibernate Search based setup is that it relies on the following flow:

  • First use the provided filter fields to search the Search backend (e.g. Elasticsearch) for a specific term (TitleDocMain:Rhein).
  • Use the returned IDs to restrict the database query, which contains the actual results, to the ones coming from the search query

Because of the hard limit of 10.000 results (from Elasticsearch/Opensearch) in a Search response the ID list might not contain all relevant (or IDs of non active processes) so the returned result from the DB is wrong. This experimental PR uses for the Excel export result set scrolling to retrieve all IDs.

@BartChris
Copy link
Collaborator Author

BartChris commented Oct 13, 2025

Additional thoughts here:

  • Why are we injecting mutiple potential large lists of IDs into the SQL query instead of building an intersection list from the multiple index queries.
  • The generated SQL already treats these lists effectively as an intersection of all passed-in IDs, but by applying large AND joined filters. Maybe we can built the intersection before in memory.
FROM Process AS process
WHERE process.project.client.id = :sessionClientId
AND process.id IN (:userFilter1query1) AND process.id IN (:userFilter1query2)
AND (process.sortHelperStatus IS NULL OR process.sortHelperStatus != :completedState) AND process.project.id IN (:projectIDs) ORDER BY process.id DESC

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.

1 participant