There is another proposal to return in the search results documents Ids, that satisfy the search condition. It would be convenient if the Wave client will give focus to first found blip after selecting the found wave.
On Tue, Jan 17, 2012 at 3:06 AM, Yuri Z <[email protected]> wrote: > > Currently the startAt index is not really used in the search results > representation, only numResults. But you are probably right. > Anyway, I am planning to work on more simple MongoDB indexing as > here<http://goo.gl/Xczzb> > . > > On Mon, Jan 16, 2012 at 9:48 PM, Andrew Kaplanov <[email protected]>wrote: > > > This is a very desirable and timely addition. Thank you very much. > > I would ask to add the following. Now interface > > org.waveprotocol.box.server.waveserver.SearchProvider consists of this > > function: > > *SearchResult search(ParticipantId user, String query, int startAt, int > > numResults);* > > I think parameter startAt not correct for the case when the results of the > > previous request has not been saved, because the data could be > > changed since the last request. > > Perhaps a better solution instead of the parameter "int startAt" add the > > parameter "SearchIndex after", where SearchIndex is a specific for search > > system object. > > For example Lucene has function > > *TopDocs searchAfter(ScoreDoc after, Query query, Filter filter, int n) * > > where "ScoreDoc after" is complex index of last search result object. > > * > > *On Sun, Jan 15, 2012 at 12:06 AM, Yuri Zelikov <[email protected]> wrote: > > > > > > ----------------------------------------------------------- > > > This is an automatically generated e-mail. To reply, visit: > > > https://reviews.apache.org/r/3508/ > > > ----------------------------------------------------------- > > > > > > Review request for wave, Michael MacFadden and Lennard de Rijk. > > > > > > > > > Summary > > > ------- > > > > > > The goal of this patch is to decouple the search implementation > > (SearchProvider) from the waves accessing logic (WaveMap). It should allow > > for alternative implementations of search providers - not dependent on > > concrete implementation of waves loading and access. The biggest problem > > with current implementation is that it requires to load all waves into > > memory on the server start up. An alternative (not memory based) search > > implementation would allow to load the waves lazily and evict later. > > > > > > > > > This addresses bug WAVE-325. > > > https://issues.apache.org/jira/browse/WAVE-325 > > > > > > > > > Diffs > > > ----- > > > > > > src/org/waveprotocol/box/server/waveserver/MemorySearchProvider.java > > PRE-CREATION > > > > > src/org/waveprotocol/box/server/waveserver/PerUserWaveViewSubscriber.java > > PRE-CREATION > > > src/org/waveprotocol/box/server/waveserver/QueryHelper.java PRE-CREATION > > > src/org/waveprotocol/box/server/waveserver/TokenQueryType.java > > PRE-CREATION > > > src/org/waveprotocol/box/server/waveserver/Wave.java PRE-CREATION > > > src/org/waveprotocol/box/server/waveserver/WaveMap.java 42eb62b > > > src/org/waveprotocol/box/server/waveserver/WaveServerModule.java 4892dc3 > > > src/org/waveprotocol/box/server/waveserver/WaveletContainerImpl.java > > ca05900 > > > > > test/org/waveprotocol/box/server/waveserver/MemorySearchProviderTest.java > > PRE-CREATION > > > > > > > test/org/waveprotocol/box/server/waveserver/PerUserWaveViewSubscriberTest.java > > PRE-CREATION > > > test/org/waveprotocol/box/server/waveserver/WaveDigesterTest.java > > 9a49ab2 > > > test/org/waveprotocol/box/server/waveserver/WaveMapTest.java 17ba0df > > > > > > Diff: https://reviews.apache.org/r/3508/diff > > > > > > > > > Testing > > > ------- > > > > > > > > > Thanks, > > > > > > Yuri > > > > >
