[
https://issues.apache.org/jira/browse/LUCENE-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882422#action_12882422
]
Robert Muir edited comment on LUCENE-2514 at 6/25/10 10:09 AM:
---------------------------------------------------------------
edit: i added newlines and reformatted so the issue is readable. sorry.
{quote}
We also need to fix FieldCache/TermRangeQuery, since they now take separate
String upper/lower. We could just add corresponding BytesRef methods?
{quote}
This actually makes the api ugly and problematic for ctors, because of
open-ended values (null). it would be nice to avoid requiring users to cast
here...
{noformat}
reference to TermRangeQuery is ambiguous, both method
TermRangeQuery(java.lang.String,java.lang.String,java.lang.String,boolean,boolean)
in org.apache.lucene.search.TermRangeQuery and method
TermRangeQuery(java.lang.String,org.apache.lucene.util.BytesRef,
org.apache.lucene.util.BytesRef,boolean,boolean)
in org.apache.lucene.search.TermRangeQuery match
[javac] TermRangeQuery query = new TermRangeQuery("content", null,
null, true, true);
{noformat}
attached is my updates to TermRangeQuery etc before realizing this. it also
includes updated FieldCacheRangeQuery complete with generics violations.
maybe when the policeman wakes up he will have ideas. i don't want the api to
be ugly.
was (Author: rcmuir):
{quote}
We also need to fix FieldCache/TermRangeQuery, since they now take separate
String upper/lower. We could just add corresponding BytesRef methods?
{quote}
This actually makes the api ugly and problematic for ctors, because of
open-ended values (null). it would be nice to avoid requiring users to cast
here...
{noformat}
[javac]
/../eclipse/workspace/solrcene-spell/lucene/src/test/org/apache/lucene/search/TestTermRangeQuery.java:100:
reference to TermRangeQuery is ambiguous, both method
TermRangeQuery(java.lang.String,java.lang.String,java.lang.String,boolean,boolean)
in org.apache.lucene.search.TermRangeQuery and method
TermRangeQuery(java.lang.String,org.apache.lucene.util.BytesRef,org.apache.lucene.util.BytesRef,boolean,boolean)
in org.apache.lucene.search.TermRangeQuery match
[javac] TermRangeQuery query = new TermRangeQuery("content", null,
null, true, true);
{noformat}
attached is my updates to TermRangeQuery etc before realizing this. it also
includes updated FieldCacheRangeQuery complete with generics violations.
maybe when the policeman wakes up he will have ideas. i don't want the api to
be ugly.
> 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-MTQPagedBytes.patch,
> LUCENE-2514-MTQPagedBytes.patch, LUCENE-2514-MTQPagedBytes.patch,
> LUCENE-2514-surrogates-dance.patch, LUCENE-2514.patch, LUCENE-2514.patch,
> LUCENE-2514.patch, LUCENE-2514.patch, LUCENE-2514.patch, LUCENE-2514.patch,
> 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
