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

Move more of the projection DSL to the engine

Description

This is low-priority, but I think that we could move parts of the implementation of projections to the engine. That would require introducing a few SPIs, but it may be doable without too much hassle, and would remove some duplicated code.

In particular, we could move most of the query-scoped parameters of the extract and transform methods to a single "parameter object" (not the "extractedData" parameter, of course).

Then we could introduce this:

1 2 3 4 public interface SearchProjectionImplementor<CE, CT, E, T> { public E extract(CE context); public T transform(CT context, E extractedData); }

That kind of interface could allow to implement the composite projections in the engine.

The main problem would be to allow SearchProjectionBuilderFactory.toImplementation to detect whether a given projection is compatible or not, since not all projections would implement the backend-specific interface any,ore.

Maybe it would be better to implement the projections in the backend, but still force them to extend this SearchProjectionImplementor interface, which would allow us to implement various objects to delegate to in the engine?

Environment

None

Status

Assignee

Unassigned

Reporter

Yoann Rodière

Fix versions

Priority

Minor