> Ard Schrijvers wrote: > I think these problems can only be solved by having all > criteria present in the index. I do not directly see how a > hierarchical cache could solve the issue. Using this cache to > filter afterwards will inherently again result in slow > results, beside the fact that the cache might become pretty > big to be effective. > > Anyway, I'll try to get back on the issue with some findings > of the current impl next week >
Thinking some more about it, perhaps we can get away without changing the index, but merely the order in which the current search is done (though i am not sure because not yet investigated so from top of my head). I think the current search checks for all hits via recursive filters wether they have the correct parents. I think though that it shouldn't be to hard to first create a filter of the initial path, for example a BitSet for something like /documents/en/news or /documents/en[1]/news or /documents/*/news or /documents/[EMAIL PROTECTED]'england']/news etc When having this filter, the rest lucene should do it trivial. Creating this filter might involve some filtering of filtering of filtered BitSet's, but I think this shouldn't be to slow, and it might be easily cached for some time. Anyway, I'll look into it Regards Ard
