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

Remove the initial call specifying the predicate type in the predicate DSL


While I was working on HSEARCH-3498, I noticed something quite interesting: this change effectively makes all predicates very similar until we call .matching or from or equivalent. So in theory we could go one step further and make the syntax even more concise by removing the initial call to .match(), .phrase(), etc.

E.g. we could move from this:

1 2 3 4 5 6 f -> f.matchAll() f -> f.match().onField( "field1" ).boostedTo( 2.0f ).orField( "field2" ).matching( value ) f -> f.match().onField( "field1" ).from( value1 ).to( value2 ) f -> f.phrase().onField( "field1" ).matching( phrase ).slop( 1 ) f -> f.simpleQueryString().onField( "field1" ).matching( queryString ).withAndAsDefaultOperator() f -> f.spatial().within().onField( "field1" ).boundingBox( ... )

To this:

1 2 3 4 5 6 f -> f.matchAll() // No change f -> f.onField( "field1" ).boostedTo( 2.0f ).orField( "field2" ).match( value ) f -> f.onField( "field1" ).from( value1 ).to( value2 ) f -> f.onField( "field1" ).phrase( phrase ).slop( 1 ) f -> f.onField( "field1" ).simpleQueryString( queryString ).withAndAsDefaultOperator() f -> f.onField( "field1" ).withinBoundingBox( ... )

I did not go this far in the PR for HSEARCH-3498, but I think we could easily do it in a later PR. Or even in a 6.1 with some deprecations, but obviously I'd rather avoid that.

I can see several advantages:

1. We have one less method call to build a predicate, and in most cases we save some characters.
2. It's more similar to the sort and projections DSLs, where we do not have this preliminary "predicate type" call and we pick a field right away: .field("fieldName", String.class) for projections, .byField( "fieldName" ) for sorts.
3. It's more "object-oriented" in the sense that the target of the predicate (the field) appears before the operation. An interesting side-effect: we could imagine to use a similar syntax in a DSL based on a static metamodel, like in QueryDSL.

On the dark side, of course, we're once again moving away from the Search 5 APIs. And we're taking some risk, too: if we end up needing field-scoped parameters that are specific to one predicate type, we will need to split the APIs once again...





Yoann Rodière


Yoann Rodière



Suitable for new contributors


Pull Request


Feedback Requested