Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 19 Sep 2006 13:15:59 +0200
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-1862) Simple hash improves performance
In-reply-to: <450EC200.1020408@apache.org>
To: derby-dev@db.apache.org
Reply-to: Andreas.Korneliussen@Sun.COM
Message-id: <450FD16F.5090506@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary=------------enig479099911D4BC070C705808D
User-Agent: Thunderbird 1.5.0.5 (X11/20060730)
References: <15758740.1158581063178.JavaMail.jira@brutus>
 <450E9F20.2090304@sun.com> <450EAB49.7090303@sun.com>
 <450EC200.1020408@apache.org>


--------------enig479099911D4BC070C705808D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Daniel John Debrunner wrote:
> Andreas Korneliussen wrote:
>=20
>> =C3=98ystein Gr=C3=B8vlen wrote:
>>
>>> Andreas Korneliussen (JIRA) wrote:
>>>
>>>
>>>> String.toUpperCase(..) with english locale, should return a string
>>>> with the same number of characters, and it should therefore be valid=

>>>> to do a check of number of characters before doing any conversions.
>>> Is it correct to always use English locale in this case?  Ref the
>>> reference guide on SQL identifiers:
>>>
>>>      An ordinary identifier must begin with a letter and contain
>>>      only letters, underscore characters (_), and digits. The
>>>      permitted letters and digits include all Unicode letters and
>>>      digits, but Derby does not attempt to ensure that the
>>>      characters in identifiers are valid in the database's
>>>      locale.
>>>
>>> Should not it be possible to match column names in any locale?
>>>
>=20
> No, see below.
>=20
>> Your question is a valid question to ask about this method, however my=

>> intention was to make the method keep its current behavior. The patch
>> simply preserves the current behaviour (which is to use english locale=
).
>> So any sets of strings s1 and s2 should make the method return the sam=
e
>> values as before the patch. If this is not the case, the patch is not =
as
>> intended.
>>
>> When looking deeper into the String class, my understanding is that th=
e
>> only Locale which has different semantics than other Locales when it
>> comes to toUpperCase(Locale..), is Turkish, so maybe Derby does not wo=
rk
>> correctly in Turkish locale.
>=20
> I think the changes were made to use a single locale (English) for the
> SQL language so that Derby would work in Turkish. Having the name
> matching in SQL be dependent on the locale of the client or engine woul=
d
> mean that the potential exists for a SQL statement from a single
> application to have different meanings in different locales. That is no=
t
> the expected behaviour when working against a programming language.
>=20
> When the SQL parser upper cased items in the engine's locale an
> application using 'insert' would fail in Turkish, as it does not upper
> case to "INSERT".
>=20
>> I also wondered why Derby has its own SQLIgnoreCase method, instead of=

>> simply using String.equalsIgnoreCase(). The Derby implementation is ve=
ry
>> inefficient compared to the String.equalsIgnoreCase() method, since yo=
u
>> risk creating two new string objects before doing the comparison.
>=20
> I think because String.equalsIgnoreCase() is dependent on the current
> locale.
>=20

String.toUpperCase() is locale dependent, however I am not sure that
String.equalsIgnoreCase() is locale dependend (does not seem so when
reading the code and javadoc).

I did find an issue with the German double s: =C3=9F.

"=C3=9F".toUpperCase() returns "SS".

However "=C3=9F".equalsIgnoreCase("SS") returns false.

So basically, "=C3=9F".toUpperCase().equalsIgnoreCase("=C3=9F") returns f=
alse.

The Derby method: SQLUtil.SQLIgnoreCase("=C3=9F", "SS") returns true (how=
ever
the patch which I attached, will make it return false and therefore is
not as intended).

If my column name is "classnames", should it be accessible by using the
string "cla=C3=9Fnames" ?

Regards
Andreas


--------------enig479099911D4BC070C705808D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFD9F036DpyYjYNyIRAhKCAKCsbeQrZJ7abLFVEmXPCecAU43xvACgh2ya
k0iSjswvKnb8IuY63YjdXcI=
=rIKi
-----END PGP SIGNATURE-----

--------------enig479099911D4BC070C705808D--