lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Klaas" <mike.kl...@gmail.com>
Subject Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted
Date Tue, 05 Dec 2006 21:38:05 GMT
On 12/5/06, negrinv <victornegrin@gmail.com> wrote:

> Chris Hostetter wrote:

> > If the code was not already in the core, and someone asked about adding it
> > I would argue against doing so on the grounds that some helpfull utility
> > methods (possibly in a contrib) would be just as usefull, and would have
> > no performance cost for people who don't care about compression.
> >
> Perhaps, if you look at compression on its own, but once you see compression
> in the context of all the other field options it makes sense to have it
> added to Lucene, it's about having everything in one place for ease of
> implementation that offsets the performance issue, in my opinion.

Note that built-in compression is deprecated, for similar reasons as
are being given for the encrypted fields.

> Finally a point about my code. I was unsuccessful in creating a diff file
> because I was picking up all kind of formatting differences as well. If you
> scan it quickly you will find that is really very simple and, at least in
> its current limited implementation, hardly invasive of Lucene's core. All
> the encryption routines are in a separate class which i placed in the
> utility package.

You can produce diffs selectively if you can't eliminate the
whitespace incoherence:
svn diff path/to/dir1 changed/path2 ...

-MIke

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


Mime
View raw message