*TO BE PONDERED*: not sure it's a good idea, we'll have to think a bit more about this. For every single predicate, we currently support targeting either one or multiple fields. When multiple fields are targeted, we basically just build the same predicate once for each targeted field, and build a boolean predicate with one "should" clause for each field. So this:
.predicate( f -> f.match().onField( "field1" )
.orField( "field2" )
.orField( "field3" )
.matching( value )
)
is actually equivalent to this:
.predicate( f -> f.bool( b -> {
b.should( f.match().onField( "field1" ).matching( value ) );
b.should( f.match().onField( "field2" ).matching( value ) );
b.should( f.match().onField( "field3" ).matching( value ) );
} ) )
or this:
.predicate( f -> f.bool( b -> {
for (String fieldName : new String[] { "field1", "field2", "field3" }) {
b.should( f.match().onField( fieldName ).matching( value ) );
}
} ) )
While this could be useful for the match and simpleQueryString predicates, where we potentially will offer additional options (such as what Elasticsearch offers for multi-match queries, see https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-multi-match-query.html#multi-match-types), I'm not sure there's a lot of value for range predicates or spatial predicates. This complicates the DSL implementation and tests quite significantly, for the sole purpose of offering some syntactic sugar. I doubt users will frequently have to define a range on "any of those fields", for example, so they could live with having to create the boolean predicate themselves. So, maybe we should only provide this feature on the match and simpleQueryString predicates? For the match predicate, we might even want to move it to a separate predicate ("multiMatch") to mirror the Elasticsearch APIs. I suspect most multiMatch options are specific to String fields, so it may actually make more sense to have a separate predicate that only works for String fields. |