Re: restricting search result
Paul wrote: Hi, how yould you restrict the search results for a certain user? I'm indexing all the existing data in my application but there are certain access levels so some users should see more results then an other. Each lucene document has a field with an internal id and I want to restrict on that basis. I tried it with adding a long concatenation of my ids ("+locationId:1 +locationId:3 + ...") but this throws a "More than 32 required/prohibited clauses in query." exception. Any suggestions? thx! Paul What about indexing security levels with the documents, as numeric value and adding the constrains you need on this field? I asume that the search will be faster in this case. Sergiu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: restricting search result
On Saturday 04 December 2004 15:44, Erik Hatcher wrote: > On Dec 4, 2004, at 6:44 AM, Paul wrote: > >> One way to restrict results is by using a Filter. > > > > but a filter is applied after the whole search is performed, isn't it? > > Incorrect. A filter is applied *before* the search truly occurs - in > other words it reduces the search space. Currently a filter is applied during search, after the document score is computed, but before a document is added to the search results. In practice, the score computation is much less work than the I/O, so a filter does reduce the search space. A filter might also be used to reduce the I/O for searching, but Lucene doesn't do that now, probably because there was little to gain. Regards, Paul Elschot. P.S. The code doing the filtering is in IndexSearcher.java, from line 97. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: restricting search result
On Dec 4, 2004, at 6:44 AM, Paul wrote: One way to restrict results is by using a Filter. but a filter is applied after the whole search is performed, isn't it? Incorrect. A filter is applied *before* the search truly occurs - in other words it reduces the search space. Here is a code example using an "owner" field to filter on: public class SecurityFilterTest extends TestCase { private RAMDirectory directory; protected void setUp() throws Exception { directory = new RAMDirectory(); IndexWriter writer = new IndexWriter(directory, new WhitespaceAnalyzer(), true); // Elwood Document document = new Document(); document.add(Field.Keyword("owner", "elwood")); document.add(Field.Text("keywords", "elwoods sensitive info")); writer.addDocument(document); // Jake document = new Document(); document.add(Field.Keyword("owner", "jake")); document.add(Field.Text("keywords", "jakes sensitive info")); writer.addDocument(document); writer.close(); } public void testSecurityFilter() throws Exception { TermQuery query = new TermQuery(new Term("keywords", "info")); IndexSearcher searcher = new IndexSearcher(directory); Hits hits = searcher.search(query); assertEquals("Both documents match", 2, hits.length()); QueryFilter jakeFilter = new QueryFilter( new TermQuery(new Term("owner", "jake"))); hits = searcher.search(query, jakeFilter); assertEquals(1, hits.length()); assertEquals("elwood is safe", "jakes sensitive info", hits.doc(0).get("keywords")); } } If you index a field that can be used for filtering purposes, QueryFilter will do the trick nicely. One recommendation when using a filter though - be sure to keep the instance around over multiple searches. QueryFilter first does a TermQuery on the term provided to pre-screen the documents available to the Query passed to the search method. Since you're doing this on a per-user basis, my recommendation is to keep their filter, once created, around in their session (in a web application) or wherever appropriate in another type of environment. The above code example is directly from Lucene in Action. I will make the complete source code distribution available early this coming week, as soon as Manning releases the electronic book edition. We have been told the e-book will be available from http://www.manning.com/hatcher2 on Monday. Rest assured Otis or I will announce it as soon as it's officially there. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: restricting search result
The thing with the different indexes sound too complecated because the users (and their rights) as well as the index itself change quite often. > One way to restrict results is by using a Filter. but a filter is applied after the whole search is performed, isn't it? I thought it might be faster to restrict the search space in advance > Using a + before each term requires them all, ie. uses AND, which > would normally have an empty result for an Id field. d'oh, yes of course.. > You might prefer this query concatenation: > > +(locationId:1 locationId:3 ...) ok, that sounds very nice and works fine. But I will have a closer look at the filter as well. Thank you all Paul P.S. someone without gmail account? mail me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: restricting search result
Paul, On Friday 03 December 2004 23:31, you wrote: > Hi, > how yould you restrict the search results for a certain user? I'm One way to restrict results is by using a Filter. > indexing all the existing data in my application but there are certain > access levels so some users should see more results then an other. > Each lucene document has a field with an internal id and I want to > restrict on that basis. I tried it with adding a long concatenation of > my ids ("+locationId:1 +locationId:3 + ...") but this throws a "More > than 32 required/prohibited clauses in query." exception. > Any suggestions? Using a + before each term requires them all, ie. uses AND, which would normally have an empty result for an Id field. You might prefer this query concatenation: +(locationId:1 locationId:3 ...) It effectively OR's the locationId content query and requires only one of the terms to match. In this case using a Filter would probably be better, though. Regards, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: restricting search result
This is entirely application-specific. As the simplest approach, you can index each user's documents in a separate index and use (Parallel)MultiSearcher to search appropriate indices (which ones are appropriate to search has to be a part of your app's access control logic). Otis --- Paul <[EMAIL PROTECTED]> wrote: > Hi, > how yould you restrict the search results for a certain user? I'm > indexing all the existing data in my application but there are > certain > access levels so some users should see more results then an other. > Each lucene document has a field with an internal id and I want to > restrict on that basis. I tried it with adding a long concatenation > of > my ids ("+locationId:1 +locationId:3 + ...") but this throws a "More > than 32 required/prohibited clauses in query." exception. > Any suggestions? > thx! > Paul > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
restricting search result
Hi, how yould you restrict the search results for a certain user? I'm indexing all the existing data in my application but there are certain access levels so some users should see more results then an other. Each lucene document has a field with an internal id and I want to restrict on that basis. I tried it with adding a long concatenation of my ids ("+locationId:1 +locationId:3 + ...") but this throws a "More than 32 required/prohibited clauses in query." exception. Any suggestions? thx! Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]