OT re Emulating Pages Search

[Jason Pump <jp...@mindspring.com>]

If the documents have some sort of fixed ranking value (pageweight) and 
the documents are arranged in the index in that order then at some point 
you can say there is no reason to look for more matches, e.g. even if 
the words were next to each other in query order, the document couldn't 
possibly score higher then my #10 result right now. In this situation 
the idea of supplying a page start/end does become valuable in reducing 
load and does not require maintaining state inside the engine. 

Jason

Erick Erickson wrote:
> Efficient in your situation, maybe. Good for everybody? Probably not.
> The key is exactly your use of the word "state". Personally, I do
> NOT want the core search engine to be stateful, that brings a whole
> raft of problems with it. And Lucene is a search engine, not a search
> application.
>
> I really don't want my underlying search engine to keep track of the
> states of many thousands of, say, web users. This, without even
> asking the question of how to keep track of the state for each
> user in a complex web application. Not to mention the added
> requirements that I somehow indicate to Lucene which user's state
> to use.
>
> And I'm not even going to go down the path of how to accomplish
> the bookkeeping for dropped sessions, timeouts, coordinating
> underlying index changes with all these states, etc. etc. etc. I think
> that if you consider the larger community, asking Lucene to
> "save its state" is much more complex that you think.
>
> That said, I can certainly imagine that there are situations where
> making the search process stateful is a good thing. But do you
> have any evidence that the current architecture actually is hurting
> you other than "theoretically"? I certainly wouldn't go down the
> stateful path until I'd demonstrated this in my situation.
>
> If, however, you'd like to make a stateful way to do things and
> submit it to the contrib section, I'm sure the guys would be
> thrilled.
>
> Erick
>
> On 4/1/07, Mohsen Saboorian <mo...@gmail.com> wrote:
>>
>>
>> This is possible, but the problem here is performance. Why is it not
>> possible
>> to support pagination in a more efficient way? Suppose, a Searcher looks
>> through Documents and find the matching ones. Theoretically, it can stop
>> searching when the result hit number gets more than a threshold. 
>> Searcher
>> may save it's state (reference to the last matched document) whithin the
>> searcher instance, making it possible for incremental search.
>>
>> What is the restriction here in Lucene indices structure, which prevents
>> us
>> from having this kind of search?
>>
>>
>> is_maximum wrote:
>> >
>> > Mosen,
>> > In order to support pagination, I wrapped the Hits is a class just 
>> like
>> > java.sql.ResultSet
>> > You can create a wrapper class and put the Hits in that and implement
>> some
>> > methods like next() prev() to forward and backward through the
>> docuements.
>> >
>> > Hope this help you.
>> >
>> > --
>> > Regards,
>> > Mohammad
>> >
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Emulating-Pages-Search-tf3500169.html#a9776722
>> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org