Isn't that an issue that comes with lots of hits in a lazyIterator anyway?
I mean, if you're only going to load up a 'few hits at a time' then you
can in theory only sort the few hits that you have loaded up anyway
right? :S
On 15/09/10 12:01, Emmanuel Bernard wrote:
You give up any hope of implementing sorting (explicit or using
relevance).
On 15 sept. 2010, at 12:16, Manik Surtani wrote:
> How about something like:
>
> - Broadcast the query
> - Every node creates the QueryHits inst, runs the query and collects
> results. Starts streaming the results back immediately.
> - The lazy iterator returns to the user immediately, and maintains an
> internal cache of results coming in from N remote QueryHits instances
> - iterator.next() blocks until this cache has available entries to return.
> - on an implementation level, the GetHItsCommand (or something like
> that) could return with a single hit, or N hits, with a flag of
> whether more hits are available or not.
>
> Does that help?
>
> Manik
>
>
> On 14 Sep 2010, at 20:46, Israel Lacerra wrote:
>
>> Hi guys,
>>
>> I'm still thinking about it, but I don't have a really good idea
>> about the lazy iterator yet. The only way (that I see) I could make
>> it more lazily is:
>>
>> - Broadcast the query.
>> - Every node creates a QueryHits instance with the query and keep it
>> in a simple little cache (array, hash, etc)
>> - A "state" of the query is created and every lazyIterator.next()
>> must send a command to a node and get the next hit (the next key).
>> - After a certain time, the instances of queryHits "dies".
>>
>> It seems to me that this is not too efficient. But I don't have any
>> other ideas.
>>
>> Do you have any suggestions about it?
>>
>> thanks!
>> Israel
>>
--
Navin Surtani
Intern Infinispan