[
https://issues.apache.org/jira/browse/LUCENE-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2514:
--------------------------------
Attachment: LUCENE-2514.patch
attached is one option: use bytesref behind the scenes but also support String
ctors like we do today.
i tried the 'hard cutover' mike suggested, but this is a massive change and I
think typically users will just be using String.
personally I don't see the harm in supporting Strings this way, any
perf-sensitive stuff creating a lot of Term objects (e.g. MultiTermQuery)
should be using BytesRef anyway.
one test fails: the preflex TestSurrogates... does this test create terms with
unpaired surrogates? If so this would explain the failures I think.
> Change Term to use bytes
> ------------------------
>
> Key: LUCENE-2514
> URL: https://issues.apache.org/jira/browse/LUCENE-2514
> Project: Lucene - Java
> Issue Type: Task
> Components: Search
> Affects Versions: 4.0
> Reporter: Robert Muir
> Attachments: LUCENE-2514.patch
>
>
> in LUCENE-2426, the sort order was changed to codepoint order.
> unfortunately, Term is still using string internally, and more importantly
> its compareTo() uses the wrong order [utf-16].
> So MultiTermQuery, etc (especially its priority queues) are currently wrong.
> By changing Term to use bytes, we can also support terms encoded as bytes
> such as numerics, instead of using
> strange string encodings.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
