Hello, We are in progress of migrating from Lucene 3.6.2 to the latest 4.6.0. One of many issues we're having is the absence of SortField constructor which had Locale parameter.
I was able to trace a similar problem/discussion at http://lucene.472066.n3.nabble.com/getLocale-of-SortField-td4076562.html in which Uwe has suggested to use SlowCollatedStringComparator from the sandbox package. My problem with the latter class is that it's javadoc suggests the class is deprecated and will be removed in Lucene v5. So very little point of using something which is scheduled for removal. My problem is that I can't use the "proper" approach as in the system which I work on the locale may not be known at the time of indexing, however, the requirement to sort by certain locale is only necessary in a few corner cases and I'm OK with the performance penalty it entails. What I don't understand is - has this slowness got worse in the last Lucene releases due to changes of algorithm internals (and if yes, by how much?) or has it stayed the same? Because surely if such an option existed earlier and people were not complaining, what's the point of removing it altogether? Why is it wrong to keep it in the sandbox with all the necessary warnings attached? Do I have any other options apart from cloning SlowCollatedStringComparator into our project repository? Regards, Mindaugas --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
