The idea is to allow users to declare filters as part of the mapping, and then allow to enable filters on an already-built query to add predicates. Users can pass parameters to the filter when enabling it.
The filters could be as simple as callbacks taking some context as a parameter and adding predicates to it using a DSL.
Note we must also allow filters to specify routing keys (“shard identifiers”) to implement the equivalent of {{org.hibernate.search.filter.ShardSensitiveOnlyFilter}}; see also HSEARCH-3314
We should think about the caching feature we have in Search 5: maybe it requires some backend-specific code, maybe it requires filters to be modeled as cacheable objects, ... and then maybe caching could be implemented exclusively at the backend level and potentially apply to every query, not just filters. See {{org.hibernate.search.util.impl.FilterCacheModeTypeHelper}} and its uses in particular. See also [this comment by Sanne|https://hibernate.atlassian.net/browse/HSEARCH-2405?focusedCommentId=89459&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-89459] which seems to suggest dropping support for filter caching would not be a big deal.
For testing, see org/hibernate/search/v6poc/integrationtest/mapper/pojo/JavaBeanProgrammaticMappingRoutingIT.java:147
|
|
