Re: [orion-dev] User Experience Call

[John J Barton <johnjbarton@xxxxxxxxxxxxxxx>]

Why isn't the indexing triggered when the file is changed instead of
rescanning the entire tree?  Surely the indexing of a single file
won't take longer than searching the entire tree.

jjb

On Wed, May 2, 2012 at 8:32 AM, Boris Bokowski <bokowski@xxxxxxxxx> wrote:
> Here's an idea that would be easy to implement: If you detect the case that
> the time of the last indexing is earlier than the time of the last change to
> the user's files, you could display (e.g. in the place of the first search
> result) that the result might be stale, and offer a way to run the query
> again.
>
> Boris
>
> On May 2, 2012, at 4:28 PM, Libing Wang <Libing_Wang@xxxxxxxxxx> wrote:
>
>>> I would be happy to wait longer for a search result if that would mean it
>>> could ensure the search index is up-to-date
>>Me too. Is this doable with the current architecture?
>
> Not sure if it is doable on server side but lets assume that server is aware
> of the "not updated yet" state when a search request is sent to a folder.
> My concern is what the UI gesture will be? Are we going to say "please wait.
> Index is being updated"?
> If that is true I would rather switching to a crawling search instead of
> waiting for index being updated, where at least I am seeing search
> progress...
>
> Libing
>
>
>
> <graycol.gif>Mike Wilson---05/02/2012 08:56:07 AM---> I would be happy to
> wait longer for a search result if that would mean it could ensure the
> search
>
>
> From: Mike Wilson/Ottawa/IBM@IBMCA
> To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
> Date: 05/02/2012 08:56 AM
> Subject: Re: [orion-dev] User Experience Call
> Sent by: orion-dev-bounces@xxxxxxxxxxx
>
> ________________________________
>
>
>
>> I would be happy to wait longer for a search result if that would mean it
>> could ensure the search index is up-to-date
> Me too. Is this doable with the current architecture?
>
> McQ.
>
>
> <graycol.gif>Kris De Volder ---2012/05/01 18:44:05---> This worked for me. I
> wonder if you typed the line and then immediately searched for it. That is a
>
>
> From: Kris De Volder <kdvolder@xxxxxxxxxx>
> To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
> Date: 2012/05/01 18:44
> Subject: Re: [orion-dev] User Experience Call
> Sent by: orion-dev-bounces@xxxxxxxxxxx
> ________________________________
>
>
>
>> This worked for me. I wonder if you typed the line and then immediately
>> searched for it. That is a big current limitation in our search - because it
>> is index based and the
>> index may not be up to date at the moment you search.
>
> It was actually quite an old file. Not something I just entered. Now that I
> try it again it actually does work.
> Not sure why it didn't work earlier. Now I'm starting to think maybe I
> imagined it :-)
>
> Problems of indexes being 'out of date' are probably adding to the feeling
> of 'unreliability' I get.
> Though I can't say whether or not this particular case was really an example
> of that.
>
> I would be happy to wait longer for a search result if that would mean it
> could ensure the search index is up-to-date
> before it starts searching.
>
> Kris
>
> ________________________________
>
> Kris De Volder <kdvolder@xxxxxxxxxx> wrote on 05/01/2012 03:27:56 PM:
>> Here's a different type of example (no white space involved).
>>
>> Say I have this line of code:
>>
>> response.end("Hello Kris");
>>
>> Now search from navigator for 'Kris'.
>>
>> It doesn't find the line above.
>
> This worked for me. I wonder if you typed the line and then immediately
> searched for it. That is a big current limitation in our search - because it
> is index based and the index may not be up to date at the moment you search.
>
> It is also definitely true that it is harder to get an index-based search to
> be "perfect" compared to a manual file system crawl on each search. We have
> been making steady improvements but I'm sure there are still problematic
> cases. On the flip side, our search is vastly more performant and scalable
> than a naive file system search. When I go back to Eclipse desktop now I am
> struck by how incredibly slow it is. I just did a search for "Kris" in my
> Eclipse desktop workspace, which isn't particularly large, and it took over
> two minutes. The same search on my Orion workspace, which is slightly
> smaller but comparable in size, took under 300ms. Performance certainly
> doesn't excuse any failure to find a match, but it's definitely a
> consideration for Orion to scale up beyond small applications and
> workspaces.
>
> Everyone please continue to report bugs if you have a search case that
> doesn't work...
>
> John
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
>
>
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
>
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
>
>
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
>