Search 6 groundwork - Consider removing the Java inheritance of standard context interfaces in DSL contexts returned by extensions


I.e replace this:

with this:

... and same for other contexts.

This will consequently prevent users from creating standard predicates/sorts/projections from a context created with an extension.


1. It's hard to make our Extension interfaces (or any other solution that allows extending APIs) work well with generics. In particular, the SearchProjectionFactoryContext has two generic parameters, and it's hard to make sure that .extension( LuceneExtension.get() ) returns a LuceneSearchProjectionFactoryContext<PojoReference, MyEntity> when applied to a SearchProjectionFactoryContext<PojoReference, MyEntity>, and not a raw LuceneSearchProjectionFactoryContext.
2. Even if we use some hacks, casts, and theoretically incorrect generics to implement a solution to the item above, that will come at a cost for users. In particular we will have to add generic parameters to the LuceneExtension/ElasticsearchExtension classes, which will take any value necessary. That means calling .extension( LuceneExtension.get() ) will work like a charm, but sorting the extension in a variable will require the user to think about these generic parameters and set them explicitly: LuceneExtension<PojoReference, MyEntity> extension = LuceneExtension.get().

This shouldn't be too bad for users, because:

1. The type of these contexts is exposed only once, when initially retrieving it. Meaning: the type is not propagated to nested lambdas (when calling .extension( LuceneExtension.get() ).bool().must( f -> ... ), f will be of the standard type once again), nor to the following contexts (when calling .extension( LuceneExtension.get() ).sort().byXXX( ... ).then(), the returned context will be of the standard type once again). If we wanted that propagation, we would have to add a "parent context" generic type parameter to almost all interfaces in the DSL.
2. It does not seem too much to ask that users call .extension( LuceneExtension.get() ) before each non-standard predicate/sort/projection they add? I wouldn't expect this to be used very often.

So the question is: which alternative is best? To be pondered carefully...




Yoann Rodière


Yoann Rodière



Suitable for new contributors


Pull Request


Feedback Requested