From users-return-19461-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Feb 13 17:47:21 2013 Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 70708E08D for ; Wed, 13 Feb 2013 17:47:21 +0000 (UTC) Received: (qmail 4741 invoked by uid 500); 13 Feb 2013 17:47:20 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 4704 invoked by uid 500); 13 Feb 2013 17:47:20 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 4696 invoked by uid 99); 13 Feb 2013 17:47:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 17:47:20 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [93.93.44.98] (HELO lanfeust.anyware.corp) (93.93.44.98) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 17:47:14 +0000 Received: from localhost (localhost [127.0.0.1]) by lanfeust.anyware.corp (Postfix) with ESMTP id 5111AA661 for ; Wed, 13 Feb 2013 18:24:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at lanfeust.anyware.corp Received: from lanfeust.anyware.corp ([127.0.0.1]) by localhost (lanfeust.anyware [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YiLaqOsa2mx for ; Wed, 13 Feb 2013 18:24:28 +0100 (CET) Received: from [172.31.2.33] (maya.anyware.corp [172.31.2.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lanfeust.anyware.corp (Postfix) with ESMTPSA id CEFC5A42E for ; Wed, 13 Feb 2013 18:24:28 +0100 (CET) Message-ID: <511BD18E.7030508@apache.org> Date: Wed, 13 Feb 2013 18:46:54 +0100 From: =?ISO-8859-1?Q?C=E9dric_Damioli?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Re: String normalization or collation? References: <511BCFD5.2020203@aperto.de> In-Reply-To: <511BCFD5.2020203@aperto.de> X-ZohoCRM-Archived: none Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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