Forum OpenACS Q&A: site-wide-search with file storage objects

Hi,
I am attempting to set up the site-wide-search so that it would work with file storage objects. I have successfully set up the interfaces and registered the object with the pot service. The content is now being indexed and I can search the content using site-side-search, however the appropriate url is not being found for file-storage-objects.

I notice that when a file storage object is created, the application_id and the node_id in table sws_search_contents are null. This differs from other object types such as bboard objects and ttracker_ticket. When these are created and the index is synchronised, the application_id and node_id are filled.

These fields should be given values when the index is synchronized and sws_service.rebuild_index is called. This calls sws_service.update_content_info for each row which in turn should fill the node_id and application_id. I am using sws_service_interface to implement the methods sws_url, sws_application_id and sws_site_node_id. These are returning null because this function is returning null:
sws_service.first_obj_type_in_context_tree (
        object_id        => object_id,
        object_type        => 'apm_package');

If I look in the database then it’s obvious that the function is returning null because there’s no object_type apm_package in the context tree for an object of type file_storage_object:
OBJECT_ID    CONTEXT_ID    OBJECT_TYPE
2287    2286    file_storage_object
2286    2119    content_item
2119    -100    content_folder
-100    0    content_folder
0        person

(I get this tree using the query:
select object_id,context_id,object_type
        from acs_objects
        start with object_id = 1390
        connect by prior context_id = object_id;)

If I look at an object where the application_id and site_node_id are being filled correctly, eg. Bboard object then I can see that there is an apm_package in the context tree:
OBJECT_ID    CONTEXT_ID    OBJECT_TYPE
1390    1389    acs_message_revision
1389    704    bboard_message
704    380    bboard_forum
380    257    apm_package
257    -3    apm_service
-3        acs_object

All this is causing problems when the results of site-wide-search include file_storage_objects. The appropriate content url for file storage objects is not being found (unless I hack it in!), so the user can’t click into the object.

I guess I need to implement my own sws_url, sws_application_id and sws_site_node_id for the file_storage_object to fix this problem. However I’m wondering if anyone has come across this before with file_storage_objects and why does a file_storage_object not have an apm_package in its context tree, while other object types do (eg. ttracker_ticket, bboard)?

Thanks in advance
Keith

Don,

So should each subsite have its own content root folder?