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@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@hibernate.org> wrote:

On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:

> 2011/4/5 Emmanuel Bernard <emmanuel@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev