You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ronnie Kolehmainen (JIRA)" <ji...@apache.org> on 2007/06/26 10:05:26 UTC
[jira] Created: (LUCENE-943) ComparatorKey in Locale based sorting
ComparatorKey in Locale based sorting
-------------------------------------
Key: LUCENE-943
URL: https://issues.apache.org/jira/browse/LUCENE-943
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Reporter: Ronnie Kolehmainen
Priority: Minor
This is a reply/follow-up on Chris Hostetter's message on Lucene developers list (aug 2006):
http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200608.mbox/%3cPine.LNX.4.58.0608211050330.5081@hal.rescomp.berkeley.edu%3e
> perhaps it would be worthwhile for comparatorStringLocale to convert the String[] it gets back from FieldCache.DEFAULT.getStrings to a new CollationKey[]? or maybe even for FieldCache.DEFAULT.getStrings to be deprecated, and replaced with a FieldCache.DEFAULT.getCollationKeys(reader,field,Collator)?
I think the best is to keep the default behavior as it is today. There is a cost of building caches for sort fields which I think not everyone wants. However for some international production environments there are indeed possible performance gains in comparing precalculated keys instead of comparing strings with rulebased collators.
Since Lucene's Sort architecture is pluggable it is easy to create a custom locale-based comparator, which utilizes the built-in caching/warming mechanism of FieldCache, and may be used in SortField constructor.
I'm not sure whether there should be classes for this in Lucene core or not, but it could be nice to have the option of performance vs. memory consumption in localized sorting without having to use additional jars.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-943) ComparatorKey in Locale based sorting
Posted by "Ronnie Kolehmainen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ronnie Kolehmainen updated LUCENE-943:
--------------------------------------
Attachment: LocaleBasedSortComparator.diff
Attached is an example SortComparator based on Locale and some tests.
> ComparatorKey in Locale based sorting
> -------------------------------------
>
> Key: LUCENE-943
> URL: https://issues.apache.org/jira/browse/LUCENE-943
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Search
> Reporter: Ronnie Kolehmainen
> Priority: Minor
> Attachments: LocaleBasedSortComparator.diff
>
>
> This is a reply/follow-up on Chris Hostetter's message on Lucene developers list (aug 2006):
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200608.mbox/%3cPine.LNX.4.58.0608211050330.5081@hal.rescomp.berkeley.edu%3e
> > perhaps it would be worthwhile for comparatorStringLocale to convert the String[] it gets back from FieldCache.DEFAULT.getStrings to a new CollationKey[]? or maybe even for FieldCache.DEFAULT.getStrings to be deprecated, and replaced with a FieldCache.DEFAULT.getCollationKeys(reader,field,Collator)?
> I think the best is to keep the default behavior as it is today. There is a cost of building caches for sort fields which I think not everyone wants. However for some international production environments there are indeed possible performance gains in comparing precalculated keys instead of comparing strings with rulebased collators.
> Since Lucene's Sort architecture is pluggable it is easy to create a custom locale-based comparator, which utilizes the built-in caching/warming mechanism of FieldCache, and may be used in SortField constructor.
> I'm not sure whether there should be classes for this in Lucene core or not, but it could be nice to have the option of performance vs. memory consumption in localized sorting without having to use additional jars.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org