[infinispan-dev] new Infinispan Query API - ISPN-194

[Sanne Grinovero]

Hi Israel,
I'm looking for ways on how to make this easier for you, but as I'm
not completely sure on what you need, let's discuss on how to get it
more flexible:

We could make the classes
org.hibernate.search.query.engine.impl.HSQueryImpl
org.hibernate.search.query.engine.impl.QueryHits
suitable for being extended (changing most private methods to
protected, and also refactor the HSQueryImpl to possibly use a
different type for QueryHits)

and then making sure that it's possible to have
org.hibernate.search.spi.SearchFactoryIntegrator.createHSQuery()
return a custom type.

(I'm assuming you have the source code of hibernate Search; if not,
you can get it from https://github.com/hibernate/hibernate-search ).

How does that look to you, is that going to suite the needs of ISPN-200 ?

Cheers,
Sanne

2011/4/10 Israel Lacerra <israeldl at gmail.com>:
> To make a LazyIterator for ISPN-200
> (https://issues.jboss.org/browse/ISPN-200) I was starting a query in each
> node and then merging the results (TopDocs) in the requester node...
>
> On Sun, Apr 10, 2011 at 6:10 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>>
>> Why do you need TopDocs? What's the use case?
>> On 10 avr. 2011, at 03:42, Israel Lacerra wrote:
>>
>> Guys,
>>
>> Do you think we can have a getQueryHits() on HSQueryImpl? To do ISPN-200 I
>> was using the TopDocs and now, with Infinispan using HSQueryImpl, TopDocs is
>> a little more hided....
>>
>> Anyway, take this just as a "suggestion". I can get the TopDocs in another
>> less fashion way :).
>>
>> cheers
>>
>> Israel
>>
>> On Tue, Apr 5, 2011 at 9:23 AM, Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>>>
>>> On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:
>>>
>>> > 2011/4/5 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> >>
>>> >> On 5 avr. 2011, at 12:20, Galder Zamarreño wrote:
>>> >>
>>> >>>
>>> >>> On Apr 4, 2011, at 6:23 PM, Sanne Grinovero wrote:
>>> >>>
>>> >>>> </snip>
>>> >>>>
>>> >>>> there's one catch:
>>> >>>> when searching for a class type, it will only include results from
>>> >>>> known subtypes. The targeted type is automatically added to the
>>> >>>> known
>>> >>>> classes, but eventually existing subtypes are not discovered.
>>> >>>>
>>> >>>> Bringing this issue to an extreme, if the query is not targeting any
>>> >>>> type, and no indexed types where added to the grid (even if some
>>> >>>> exist
>>> >>>> already as they might have been inserted by other JVMs or previous
>>> >>>> runs), all queries will return no results.
>>> >>>> How to solve this?
>>> >>>> - class scanning?
>>> >>>
>>> >>> Nope, too expensive.
>>> >>>
>>> >>>> - explicitly list indexed entities in Infinispan configuration?
>>> >>>
>>> >>> No
>>> >>>
>>> >>>> - a metadata cache maintaining a distributed&stored copy of known
>>> >>>> types
>>> >>>
>>> >>> That sounds more appealing. It could be a good middle ground until
>>> >>> Search can search for types.
>>> >>
>>> >> Do you have any specific idea in mind?
>>> >>
>>> >> To magically find types:
>>> >>  - we scan every file system, databases, caches available to the app
>>> >> and look for Lucene metadata => unrealistic
>>> >>  - there is some kind of convention on where the indexes are and we do
>>> >> index scanning at startup => scanning are very likely to be slower that
>>> >> class scanning (potential remote access, bigger dataset etc)
>>> >>  - we enforce one or a fixed number of Lucene indexes for all data in
>>> >> Infinispan => not sure that's a good idea but this can be explored
>>> >>  - we somehow ask the framework using HSearch to fill up classes
>>> >>
>>> >> other approaches?
>>> >
>>> > why was class scanning discarded in the first answer? as H. Search can
>>> > auto-discover classes by working on top of JPA entity autodiscovery, I
>>> > guess that each application node could look into it's own known
>>> > classpath.
>>> > After all if some type is not visible to him as it was added from
>>> > another node from a different app, he won't be able to return
>>> > instances of it either.
>>> > We could face the opposite problem of building metadata of classes
>>> > people doesn't mean to index in this cache.
>>>
>>> Right. scanning (class or index) will be a bit aggressive and could build
>>> unneeded metadata (or even worse, return unexpected classes).
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>
>