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

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

Description

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

Environment

None

Status

Assignee

Yoann Rodière

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Priority

Major