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

Allow mappers to expose extended *FactoryContext interfaces to their users

Description

If we were to introduce a <S> generic parameter in the factory contexts in the various DSLs, we might be able to allow this kind of thing:

1 2 3 4 mapperSearchTarget.query().asProjection( f -> f.someMapperSpecificProjection() ) .predicate( f -> f.someMapperSpecificPredicate() ) .sort( f -> f.someMapperSpecificSort() ) .build()

I suspect the "fluent" syntax was the main problem preventing us from introducing that kind of thing. Now that it's gone, maybe we can improve it.

Some items that could be pulled up to mapper-specific interfaces (just expose the necessary hooks in SPIs)

  • .reference() projection

  • .object() projection

  • .type(Class<?>) predicate (see HSEARCH-3434)

Ideally the <S> type should be propagated to composite contexts (boolean predicates, composite projections, basically all sorts, ...), so that uses of the lambda syntax in these contexts (f.bool().must( f -> ... ) correctly provide an "extended" type to the user.

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