Postponed
Project:
Search Files
Version:
6.x-2.0-beta1
Component:
Code
Priority:
Minor
Category:
Task
Assigned:
Reporter:
Created:
3 Jul 2009 at 14:39 UTC
Updated:
28 Aug 2009 at 18:44 UTC
Hi
I have so far used some of the old search_attachments module to enhance the normal search so it also includes attachments. But this is looking very good and I'm thinking of changing over to it. Two things, though, I've found from looking at the code and which might be worth adding to it are:
$cache_text = cache_get("file_text:".$fid);
if ($cache_text && is_object($cache_text) && $cache_text->data) {
$file_text .= " " . $cache_text->data;
...
cache_set("file_text:".$file->fid, $new_text);
$full_path = $_SERVER['DOCUMENT_ROOT'] . '/' . file_directory_path() . '/' . $file->filepath;
My apologies if this has already been dealt with.
All the best
Comments
Comment #1
thl commented1.) caching of content
What exactly do you believe is worth caching? If the output from all helper applications will be cached in the database, we likely end up doubling the disk space requirements.
2.) file system path
see #556790: Filepath/URI handling in Search Files Attachments
Fixed in CVS past Beta3
Comment #2
miiimooore 1) The cache only holds the text version. In many cases a PDF document or office document can be several MB and still the text is a couple of KB. I have one here that uses around 300MB of disk space for documents and the cache table is 1.7MB.
The main advantage of caching is that when you display search results you don't have to run the helper for each result to get an excerpt which can put considerable load on the CPU and make this very slow.
As a compromise maybe you could add a configuration switch. Then users could chose depending on their hosting environment.
Comment #3
thl commentedDefer performance improvements past 6.x-2.0 release.