Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Users List" <lucene-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <20041219220558.94528.qmail@web41210.mail.yahoo.com>
References: <20041219220558.94528.qmail@web41210.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <F655FB0E-5274-11D9-BC04-000393A564E6@ehatchersolutions.com>
Content-Transfer-Encoding: quoted-printable
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: Optimising A Security Filter
Date: Mon, 20 Dec 2004 05:50:28 -0500
To: "Lucene Users List" <lucene-user@jakarta.apache.org>

Paul already replied, but I'll add my thoughts below to the thread=20
also...

On Dec 19, 2004, at 5:05 PM, Steve Skillcorn wrote:
> I bought the Lucene in Action ebook, which is
> excellent and I can strongly recommend.

Thank you!!!!

> Does the IndexReader that is passed to the =93bits=94
> method of the filter represent the entire index, or
> just the results that match the query?

It represents the entire index at the time it was instantiated.  This=20
is important to know in case documents are later added to the index.

> Is not worrying about filters and simply checking the
> returned Hit List before presenting a sensible
> approach?

It depends.  Is the performance of checking a relational database for=20
the results being shown to the user acceptable?  Is the security risk=20
of a new piece of code forgetting to check the results of a search=20
worth it?

> I can see the point to filters as presented in the
> Lucene in Action ISBN example, but are they a good
> approach where they could end up laboriously marking
> the entire index as True?

Iterating through every document in the index certainly is time=20
consuming and not something you should do for every search.  However,=20
filters are designed to be long-lived.  Write your filter to simply do=20=

the logic of checking each document against the database, then wrap=20
your filter with the caching wrapper.  Be sure to use the same=20
IndexReader for each search.  When the index changes, rebuild the=20
filter.

There is no clear best way to do this type of filtering of results, I=20
don't believe.  There are details to consider for either of these=20
approaches.

> All help greatly appreciated.  Thanks to the authors
> for Lucene in Action, it's given me the high level
> best practices I was needing.

Steve - I really appreciate hearing this.  Putting this work to public=20=

scrutiny opens the possibilities of opinion.  Your comments hearten me.

	Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org