db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tiago R. Espinha (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-728) Unable to create databases whose name containg Chinese characters through the client driver
Date Mon, 28 Jun 2010 23:02:53 GMT

     [ https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Tiago R. Espinha updated DERBY-728:

    Attachment: DERBY_728_p2_sanity.diff

I'm attaching two patches to this issue.

The first, DERBY_728_p2_sanity.diff aims at fixing an issue with sanity. I was making calls
to the SanityManager without a check to verify that the DEBUG was enabled. A question that
remains open is: what do we do with the exception on a sane build? Is it ok to muffle it and
only deal with it on insane mode?

The second patch, DERBY_728_p3.diff, should in principle enable UTF-8 support in the server.
I'm not sure I've missed something but I'll post a short explanation of what I've done:

- CodePoint.java
Inserted the new code point for UNICODEMGR (0x1C08) as per the ACR and added it to the MGR_CODEPOINTS

- NetworkServerControlImpl.java
Set the minimum manager level for the UNICODEMGR in synch with the MGR_CODEPOINTS array.

- AppRequester.java
Set the minimum manager level for the UNICODEMGR in synch with the MGR_CODEPOINTS array.

Also added a convenience method that tells us whether the AppRequester depicted by this class
supports or not UTF8. This relies on the manager level for UNICODEMGR being greater or equal
to 1208. If the requester does not support UTF8, we won't get a UNICODEMGR manager level on
the EXCSAT and as such UNICODEMGR will be set to 0 (which means this convenience method will
return false).

- DRDAConnThread.java
When dealing with the ACCSEC code point and after we send the ACCSECRD reply we check whether
the appRequester supports UTF8 and if it does, we enable it through the switchToUtf8() method
[also part of the patch]. If it doesn't, make sure it goes back to EBCDIC, to make sure we
aren't in UTF8 from the previous connection.

I'm not sure how I'd go about testing this as a client would have to support UTF-8 as well
to be able to test it and this is still just the server side implementation. It will be a
good test though to see if all regressions pass tonight; tomorrow, provided that this patch
seems to be ok, I will do testing with older clients and see what the outcome is.

> Unable to create databases whose name containg Chinese characters through the client
> -------------------------------------------------------------------------------------------
>                 Key: DERBY-728
>                 URL: https://issues.apache.org/jira/browse/DERBY-728
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>         Environment: Debian unstable, LInux, libc 2.3.5-6
>            Reporter: Andrei Badea
>            Assignee: Tiago R. Espinha
>         Attachments: ACR7007.pdf, BigTableName.java, derby-728-startingpoint.diff, DERBY-728_p1.diff,
DERBY-728_p2-test.diff, DERBY-728_p2-test.diff, DERBY-728_p2-test.diff, DERBY-728_p2-test.diff,
DERBY-728_p2.diff, DERBY-728_p2.diff, DERBY-728_p2.diff, DERBY-728_p2.diff, derby-728_proto_diff.txt,
DERBY_728_p2_sanity.diff, DERBY_728_p3.diff
> Trying to create a database with the following URL (note the Chinese character in the
database name):
> jdbc:derby://localhost:1527/\u4e10;create=true
> throws the following exception:
> -----%<-----
> Exception in thread "main" org.apache.derby.client.am.SqlException: Unicode string can't
convert to Ebcdic string
>         at org.apache.derby.client.net.EbcdicCcsidManager.convertFromUCS2(Unknown Source)
>         at org.apache.derby.client.net.Request.writeScalarPaddedString(Unknown Source)
>         at org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source)
>         at org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source)
>         at org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown
>         at org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
>         at org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
>         at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
>         at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
>         at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
>         at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
>         at java.sql.DriverManager.getConnection(DriverManager.java:525)
>         at java.sql.DriverManager.getConnection(DriverManager.java:193)
>         at jdbctest.Main.main(Main.java:33)
> -----%<-----
> It's possible, however, to create databases using the embedded driver, using an URL like:
> jdbc:derby:\u4e10;create=true
> Tested with both and with the same result.
> Complete code to reproduce the bug:
> -----%<-----
> public static void main(String[] args) throws Exception {
>     Class.forName("org.apache.derby.jdbc.ClientDriver");
>     Connection conn = DriverManager.getConnection("jdbc:derby://localhost:1527/\u4e10;create=true");
> }
> -----%<-----

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message