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/bd56fee00464f9... 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 :)

On Feb 19, 2011, at 1:41 AM, Sanne Grinovero wrote: > 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? This will probably be merged within a week or two. > > 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. You tell us if the core of mass indexer should be reusable or not. That can definitely be done in a second step.

I have to add a third point: Infinispan's Query has a "LazyIterator" functionality, which is really lazy (opposing to Search's scrollable result) it expects the IndexSearcher to not be closed while the user iterates, and expects the user to close this.

I'm not a big fan for this feature, so for the moment I ported all the rest and all tests are green by just returning a non-lazy iterator: https://github.com/Sanne/infinispan/tree/ISPN-952 Options: - drop the feature - expose a similar feature in Hibernate Search, implement it in HSQuery - keep using the non-public "low-level" methods in Query

Sanne 2011/2/23 Sanne Grinovero <sanne(a)hibernate.org&gt;: > I've been trying to port current work in progress as dependency of > Infinispan Query, > I'm wishing for these changes: > > 1) TimeoutManager should throw specific exceptions directly, depending > on the framework being used > (see the pull request I sent you [1], I think it solves the issue, we > might want to polish it a bit to have the JPA interface define it's > own specific factory. > > 2) The org.hibernate.search.engine.Loader interface: > I'd just remove the init() method from the interface. > Infinispan Query needs quite different types and parameters (and > definitely not a Session), and I see no reason to have the init method > expressed by the interface contract. > Each framework should know how to create and initialize his specific loaders. > > For the rest, it's great! this is removing a lot of code duplication, > and consequently improving Query with all latest bugfixes and features > from Search. > > Cheers, > Sanne > > > 2011/2/21 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> >> On Feb 19, 2011, at 1:41 AM, Sanne Grinovero wrote: >> >>> 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? >> >> This will probably be merged within a week or two. >> >>> >>> 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. >> >> You tell us if the core of mass indexer should be reusable or not. That can definitely be done in a second step. >> >> >

>> >> I'm not a big fan for this feature, so for the moment I ported all the >> rest and all tests are green by just >> returning a non-lazy iterator: >> >> https://github.com/Sanne/infinispan/tree/ISPN-952 >> >> Options: >> - drop the feature >> - expose a similar feature in Hibernate Search, implement it in HSQuery >> - keep using the non-public "low-level" methods in Query > > which non public method are you talking about? I was referring mostly the DocumentExtractor and EntityInfo, but thinking about it that's not so bad. Will both of them, or an abstraction of them, be available at SPI level?

> 1) TimeoutManager should throw specific exceptions directly, depending > on the framework being used > (see the pull request I sent you [1], I think it solves the issue, we > might want to polish it a bit to have the JPA interface define it's > own specific factory. I'll have a look

On 23 févr. 2011, at 18:13, Sanne Grinovero wrote: > I've been trying to port current work in progress as dependency of > Infinispan Query, > I'm wishing for these changes: > > 1) TimeoutManager should throw specific exceptions directly, depending > on the framework being used > (see the pull request I sent you [1], I think it solves the issue, we > might want to polish it a bit to have the JPA interface define it's > own specific factory. I'll have a look > > 2) The org.hibernate.search.engine.Loader interface: > I'd just remove the init() method from the interface. > Infinispan Query needs quite different types and parameters (and > definitely not a Session), and I see no reason to have the init method > expressed by the interface contract. > Each framework should know how to create and initialize his specific loaders. Loader is not a public API. If we ever expose it, that's going to be fore Hibernate Core's object loading. In other words, I have the feeling that Loader cannot be reused between various object sources. Does ISPN's Query module use them? Did you manager to reuse much code in practice?