[
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
DERBY_728_p3.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 array.
--
- 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 driver
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-728
> URL: https://issues.apache.org/jira/browse/DERBY-728
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.1.2.1
> Environment: Debian unstable, LInux 2.6.14.2, 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
> Source)
> at
> org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
> Source)
> 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 10.1.1.0 and 10.1.2.1 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.
