Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Mon, 04 Jun 2007 17:10:08 +0200
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-1519) 'setAsciiStream' uses different
 encodings for embedded and client
In-reply-to: <wjo8bqg05a9v.fsf@sun.com>
Sender: Kristian.Waagan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <46642B50.5090907@Sun.com>
Organization: Sun Microsystems Inc.
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <1285987.1180630816205.JavaMail.jira@brutus>
 <465F0DF9.5080604@sbcglobal.net> <465FCE19.3090800@Sun.com>
 <wjo8bqg05a9v.fsf@sun.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; no-NO;
 rv:1.8.1.3) Gecko/20070419
 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0

Knut Anders Hatlen wrote:
> Kristian Waagan <Kristian.Waagan@Sun.COM> writes:
> 
>> Mike Matrigali wrote:
>>>  From the description in the bug this seems like the right change, but
>>> it does seem like it may also be another incompatibility.  Should it
>>> be added to the wiki?  What difference will an app that somehow
>>> depended on the old (wrong) behavior see now?
>> I think the only difference is that where you previously inserted a
>> character outside US-ASCII and got a '?' back, you will now get the
>> actual character back.
>>
>> A typical example is the three "extra" Norwegian/Danish letters.
>>
>> So the patch might change what goes in and what comes back.
>> Personally I think people needing these characters are already using
>> setCharacterStream (or another mechanism handling the issue), and
>> would not be affected.
>> And people using only US-ASCII for input would not be affected either.
>> The only case where it can affect input/output is when the input is
>> something like ISO-8859-1, but as I said, I think this case is handled
>> differently by the users.
>>
>> Just my thoughts. There is maybe a slight incompatibility, but due to
>> its nature I think it is acceptable.
>>
>> So, what did I forget about? :)
> 
> You could also have applications that pass the contents of a clob to a
> library/method that only knows how to handle US-ASCII. If
> getAsciiStream() starts using ISO-8859-1 (as it should), those
> applications could get strange errors because Derby previously would
> have masked non-US-ASCII characters as question marks. I don't think
> this is a blocker, but perhaps it would be appropriate with a release
> note?
> 

I want to get this fix in due to tests for Clob, which breaks if this is 
not fixed.

Can I get another opinion on the need for a release note?

I'm having a little trouble writing meaningful words in the various 
sections, but I have added a draft to the Jira.


thanks,
-- 
Kristian