[hibernate-dev] [HSEARCH] Extract core of HSEARCH query engine to be independent of Hibernate Core.

[Sanne Grinovero]

great, thank you. Pulled this so I can have a look tomorrow, when I'll
have 10h train.
Are you only looking for feedback, or do you think something should be
merged already?

What is the fate of the MassIndexer ? Even if I managed to abstract it
from Hibernate I wonder how much the general concept would be
appropriate for other integrations, so I'd move it away with the
hibernate specific code. In case we change minds we can move it back
into core later.

Cheers,
Sanne

2011/2/18 Emmanuel Bernard <emmanuel at hibernate.org>:
> In the last two days, I've worked on extracting the Hibernate Search specific knowledge of the query engine.
> The goals are:
>  - let it be reused by Infinispan and other object sources
>  - isolate Hibernate Search from Core (longer goal
>
> Here is the branch
> https://github.com/emmanuelbernard/hibernate-search/commits/HSEARCH-687
> and the commit
> https://github.com/emmanuelbernard/hibernate-search/commit/bd56fee00464f9e0e5660561764fede9e22f8980
>
> This is super early  design but Sanne can you check it out to see if it would fit Infinispan's Search module. Check FullTextQueryImpl and ScrollableResultsetImpl for examples on how to use the SPI.
>
> Still TODO
>  - Move DocumentExtractor and EntityInfo to query.engine?
>  - Expose a different object than DocumentExtractor (it hosts first/max and searcher for ScrollableRS which is not really correct)
>  - Make EntityInfo presentable
>  - Isolate TimeoutManager?
>  - Make Loader hierarchy depend on HSQuery?
>  - Refactor some code out of Loader implementations? At first sight, it's not necessary
>  - accept the fact that SearchFactoryImplementor becomes a SPI?
>  - create a factory for HSQuery from SearchFactoryImplementor and make HSQuery an interface
>  - more interfaces (EntityInfo, DocumentExtractor)?
>
> The usage is still complex especially TimeoutManager but it's a lot better than what we had :)