[
https://issues.apache.org/jira/browse/LUCENE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772180#action_12772180
]
Robert Muir edited comment on LUCENE-2019 at 10/30/09 11:41 PM:
----------------------------------------------------------------
bq. So you think that enforcing consistency is worth the cost of disallowing
some usages, and I don't.
no, i think this a myth. I think this is the original bug that caused index
corruption
* lucene used a noncharacter (happened to be U+FFFF) process-internally
* lucene also treated this noncharacter as an abstract character (it later got
truncated by some encoding routine, but basically it didn't correctly handle
this case)
by disallowing all noncharacters as term text, lucene is *more free* to use
them as delimiters, and sentinel values, and such, as specified in chapter 3 of
the standard.
right now you only have one you treat correctly, and thats U+FFFF.
<edit>
Steven, by the way, I think something i havent been able to communicate
properly, is that I feel very strongly that storing noncharacters in *term
text* where they are treated as abstract characters, is very different than
using them as sentinel values / delimiters / etc in the index format, I think
this is ok and is what they are for.
but term text is different, search engines index human language and by putting
noncharacters in term text you are treating them as abstract characters.
was (Author: rcmuir):
bq. So you think that enforcing consistency is worth the cost of
disallowing some usages, and I don't.
no, i think this a myth. I think this is the original bug that caused index
corruption
* lucene used a noncharacter (happened to be U+FFFF) process-internally
* lucene also treated this noncharacter as an abstract character (it later got
truncated by some encoding routine, but basically it didn't correctly handle
this case)
by disallowing all noncharacters as term text, lucene is *more free* to use
them as delimiters, and sentinel values, and such, as specified in chapter 3 of
the standard.
right now you only have one you treat correctly, and thats U+FFFF.
> map unicode process-internal codepoints to replacement character
> ----------------------------------------------------------------
>
> Key: LUCENE-2019
> URL: https://issues.apache.org/jira/browse/LUCENE-2019
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Robert Muir
> Priority: Minor
> Attachments: LUCENE-2019.patch
>
>
> A spinoff from LUCENE-2016.
> There are several process-internal codepoints in unicode, we should not store
> these in the index.
> Instead they should be mapped to replacement character (U+FFFD), so they can
> be used process-internally.
> An example of this is how Lucene Java currently uses U+FFFF
> process-internally, it can't be in the index or will cause problems.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
