Search 6 groundwork - Restore support for applying bridges automatically to predicate/sort DSL parameters


In Search 5, by default, when you call queryBuilder.keyword().onField( "myField" ).matching( <some value> ), the value is expected to be transformed by the field bridge before being used to create a predicate. When you call queryBuilder.keyword().onField( "myField" ).ignoreFieldBridge().matching( <some value> ), the field bridge is skipped.

In Search 6, until now, we did not use the bridge in the DSL. We should offer a way to do so.

We need to:

  1. Decide how to allow bridges to implement this transformation. For ValueBridges it's simple, as they expose a method to transform a value to its indexed form. For other TypeBridge and PropertyBridge it's not as straightforward, because those bridges may manage multiple fields so a query on a given "object property" might require multiple queries on multiple fields.

  2. Decide whether we want to rename the @Field annotation to something more consistent with the new name of the onXXX methods in the DSL. Maybe @ValueBridge would make more sense. Or maybe @MapToField, to highlight the fact the annotation is not about marking the object property as a "field", it's about mapping it to a field, which is separate from the object property.

  3. Add support for the mapper to forward some information to the engine when bootstrapping, so that the predicate DSL (implemented in the engine, thus below the mapper) can somehow use bridges.


For tests, see:

  • Occurrences of the string “TODO rely on the bridge to convert to a String” in the showcase

  • Occurrences of the string “TODO rely on the bridge to split the String” in the showcase




Yoann Rodière


Yoann Rodière



Suitable for new contributors


Feedback Requested



Fix versions