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 <sa...@hibernate.org>: > 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 <emman...@hibernate.org>: >> >> 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. >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev