Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of joerg.frantzius@aperto.de
 designates 213.61.132.20 as permitted sender)
Message-ID: <511E1309.3020308@aperto.de>
Date: Fri, 15 Feb 2013 11:50:49 +0100
From: =?ISO-8859-1?Q?J=F6rg_von_Frantzius?= <joerg.frantzius@aperto.de>
Organization: aperto AG, Berlin
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: String normalization or collation?
References: <511BCFD5.2020203@aperto.de> <511BD18E.7030508@apache.org>
In-Reply-To: <511BD18E.7030508@apache.org>
Content-Type: multipart/alternative;
 boundary="------------030908090108040902080909"

--------------030908090108040902080909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi C�dric,

thanks for your answer here and in JIRA.

Out of curiosity, does that mean that the comparator works on values 
from the underlying database, and not from Lucene index?

For anybody interested and reading here, I opened 
https://issues.apache.org/jira/browse/JCR-3522 for porting of a 
NORMALIZE() function to SQL2.

Regards,
J�rg

On 13.02.2013 18:46, C�dric Damioli wrote:
> Hi J�rg,
>
> Your approach won't work with the current implementation as the order 
> clauses are not "analyzed", so changing the analyzer won't have any 
> effect.
> It should be possible to add a NORMALIZE() function also in the 
> SQL/SQL2 grammar, reusing the NormalizeSortComparator introduced by 
> JCR-3443
>
> Regards,
> C�dric
>
> Le 13/02/2013 18:39, J�rg von Frantzius a �crit :
>> Hi,
>>
>> we've got the problem that our SQL2 queries with ORDER BY clauses on 
>> Strings do sort the Germans Umlauts at the end of the results, while 
>> Umlauts should be sorted like their equivalent characters without the 
>> accent (e.g. "�" = "o").
>>
>> According to https://issues.apache.org/jira/browse/JCR-3443, with 
>> Jackrabbit 2.5.3 it should be possible to have a normalize() function 
>> in XPath queries, but not in SQL2.
>>
>> We're now thinking of modifying the Jackrabbit configuration, and in 
>> particular setting the "analyzer" param to the SearchIndex with a 
>> custom subclass of 
>> org.apache.lucene.analysis.standard.StandardAnalyzer, which makes use 
>> of a 
>> https://lucene.apache.org/core/old_versioned_docs/versions/3_0_3/api/core/org/apache/lucene/analysis/ASCIIFoldingFilter.html 
>> .
>>
>> Does anybody per chance have an opinion whether that could be a 
>> viable approach?
>>
>> Thanks for answers + regards,
>> J�rg
>>
>>
>> -- 
>> C�dric Damioli
>> Ametys CMS
>> http://www.ametys.org
>> http://www.anyware-services.com


-- 
*Dipl. inf. J�rg von Frantzius, System Architect*

Email mailto:joerg.frantzius@aperto.de
Phone +49 30 283921-318
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestra�e 5, D-10115 Berlin-Mitte
http://www.aperto.de
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro�mann, Stephan Haagen
Aufsichtsrat: Bernd Hardes (Vorsitzender)

--------------030908090108040902080909--