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

[Sanne Grinovero]

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 at 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 <emmanuel at 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.
>>
>>
>