[
https://issues.apache.org/jira/browse/SOLR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009630#comment-13009630
]
Robert Muir commented on SOLR-2396:
-----------------------------------
bq. A rough idea: It seems that ICU Collator Keys are null-terminated.
This isn't always the case, at least at query-time for example if you are using
a bound mode
(http://icu-project.org/apiref/icu4j/com/ibm/icu/text/CollationKey.BoundMode.html)
I think for the UPPER_LONG case it does not exist.
But, in any case I think we can't rely upon the fact that ICU might currently
avoid zero bytes: this isn't really specified anywhere and just an optional
impl detail (http://unicode.org/reports/tr10/#Avoiding_Zero_Bytes)
> add [ICU]CollationField
> -----------------------
>
> Key: SOLR-2396
> URL: https://issues.apache.org/jira/browse/SOLR-2396
> Project: Solr
> Issue Type: Improvement
> Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: SOLR-2396.patch, SOLR-2396.patch, SOLR-2396.patch,
> SOLR-2396.patch
>
>
> In LUCENE-2551 collation support was changed to use byte[] keys.
> Previously it encoded sort keys with IndexableBinaryString into char[],
> but this is wasteful with regards to RAM and disk when terms can be byte.
> A better solution would be [ICU]CollationFieldTypes, as this would also allow
> locale-sensitive range queries.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
