Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 375947

Summary:	Can't search an alternate file service
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Client	Assignee:	libing wang <libingw>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	ken_walker, libingw
Version:	0.5
Target Milestone:	1.0 RC1
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Mark Macdonald

2012-04-03 09:54:21 EDT

Orion I20120401-2230

1. Install an add-on file service (like S3, webdav, etc).
2. Use the Navigator to browse into the file service.
3. Type a query into the search box, press Enter.
4. You get results for the Orion file service (/file/), not the one you were browsing.

From what I could see, it looks like support exists in the FileClient API for searching. However, the necessary parameters (fileService, location) are not passed to the search page, so it defaults to your Orion files every time.

Comment 1 Ken Walker

2012-04-03 09:58:29 EDT

Libing was going to investigate a crawling search approach for file systems that don't inherently support search results like the Orion file system.

Comment 2 libing wang

2012-04-03 10:30:40 EDT

I have a webDav in my workspace. If I click on my webDav on the left pane and do search it prompt me "search is not supported in this file system", which makes sense for now.
As Ken mentioned, I will experiment a crawling search soon but what Mark mentioned seems to be another file service mismatch issue. Will talk to him.

Comment 3 libing wang

2012-04-03 11:45:46 EDT

There is a logic when we judge if we need a "+Location" parameter in search query, implemented in setLocationByMetaData function in searchClient.js:
If your file meta(even it is in your root) does not have "Parents" property, then we think you are in the file system ROOT and we don't put "+Location" parameter in search. Hence in search page it can't locate your file service and it will go to Orion file service.

In webDav case, the meta data at root provides an empty "Parents" array so that we know that we have to use the meta.Location for search. Then we can locate its file service in search page and know its search API is not available. 

So if your implementation provides the empty "Parents" at root, at least we will prompt the "search not supported" message.

Ideally, we should provide a "SearchLocation" in the meta data no matter it is root or not. Orion file service has that property but the value is wrong and not used.

Comment 4 Mark Macdonald

2012-04-03 18:00:58 EDT

Thanks for looking into this, Libing. I'll change my file service so it provides an empty 'Parents' array for the root.

Also, I started a detailed documentation of the file API at [1] to capture subtleties like this one. We can use this doc to pick out parts of the API that need to be evolved/simplified.

[1] http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Core_client_services#orion.core.file

Comment 5 libing wang

2012-10-04 17:07:41 EDT

We now have the ability to search on a file system that does not support "search" API, by a crawler.