[
https://issues.apache.org/jira/browse/LUCENE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683993#action_12683993
]
Uwe Schindler edited comment on LUCENE-652 at 3/20/09 12:09 PM:
----------------------------------------------------------------
This is a first version using UnicodeUtils. The deprecated Store.COMPRESS part
still uses String.getBytes() because of backwards compatibility (otherwise it
would be a change in index format).
This version currenty creates a new UTFxResult, because no state and no close
method. It can also be synchronized without ThreadLocal, but this may not be so
good.
The current version has a little performance impact because of array copying.
was (Author: thetaphi):
This is a first version using UnicodeUtils. The deprecated Store.COMPRESS
part still uses String.getBytes() because of backwards compatibility (otherwise
it would be a change in index format).
This version currenty creates a new UTFxResult, because no state, so not close
method. It can also be synchronized or without ThreadLocal, but this may not be
so good.
The current version has a little performance impact because of array copying.
> Compressed fields should be "externalized" (from Fields into Document)
> ----------------------------------------------------------------------
>
> Key: LUCENE-652
> URL: https://issues.apache.org/jira/browse/LUCENE-652
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 1.9, 2.0.0, 2.1
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-652.patch, LUCENE-652.patch, LUCENE-652.patch
>
>
> Right now, as of 2.0 release, Lucene supports compressed stored fields.
> However, after discussion on java-dev, the suggestion arose, from Robert
> Engels, that it would be better if this logic were moved into the Document
> level. This way the indexing level just stores opaque binary fields, and
> then Document handles compress/uncompressing as needed.
> This approach would have prevented issues like LUCENE-629 because merging of
> segments would never need to decompress.
> See this thread for the recent discussion:
> http://www.gossamer-threads.com/lists/lucene/java-dev/38836
> When we do this we should also work on related issue LUCENE-648.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
