db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-1519) 'setAsciiStream' uses different encodings for embedded and client
Date Fri, 01 Jun 2007 08:50:04 GMT
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

Knut Anders

View raw message