[jira] Commented: (DERBY-4009) Accommodate length delimited DRDA strings where character length does not equal byte length

["Tiago R. Espinha (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873651#action_12873651 ] 

Tiago R. Espinha commented on DERBY-4009:
-----------------------------------------

I was going through the derby/client/net/Request class and I have some questions.

@ Kathey, should I rely on the code you have provided for the writeScalarString() method? You mentioned some performance concerns and I have been trying to understand the code without much luck. Maybe you can help me here. 

For example, why do we always shift the codePoint right by 8 bits? Also, we do a «logical and» with binary 255 twice, does this have a reason? If we «AND» a byte against 255 doesn't that always give us the initial byte?

We also have some hardcoded values that I would like to convert into constants, or at least put some inline comments explaining exactly what they are. For instance, at some point we increment the offset by 2 and before this we also invoke ensureLength() by adding the offset_, maxByteLength and 4. Why 4?


Finally, I'll be submitting a patch later today that addresses EXTNAM, PRDID, SRVCLSNM, SRVNAM, SRVRLSLV and TYPDEFNAM as these seem to be the only codepoints that actually write strings of variable size. There are fields like RDBACCCL that just write bytes or words and to my understanding, these will be left untouched, as these are not encoding strings into bytes.

> Accommodate  length delimited DRDA strings where character  length does not equal byte length
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4009
>                 URL: https://issues.apache.org/jira/browse/DERBY-4009
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Client, Network Server
>    Affects Versions: 10.5.1.1
>            Reporter: Kathey Marsden
>            Assignee: Tiago R. Espinha
>            Priority: Minor
>         Attachments: derby-4009-sample_diff.txt, derby-4009_a_diff.txt, derby-4009_sample2_diff.txt
>
>
> Currently the drda code in server and client assumes that the byte length of ddm parameters is equal to the character length.  In the fix for DERBY-728, ddm parameters such as RDBNAM will be in UTF-8 and the character and byte length may not match.  The code needs to allow for this.
> The primary purpose of this Jira is to enforce the DRDA length checking which is in bytes.  For example for RDBNAM (database name), the limit  is 255 bytes in length, not 255 characters.   The limits are somewhat arbitrary and sad in my opinion. Certainly for Derby there should be no problem  removing the limits, except for the DRDA spec constraint. With DERBY-728 and the introduction of UNICODEMGR, characters can take up to 4 bytes, so the calculation is more difficult.
> (I actually tried to sneak removing or expanding the limits in the ACR 7007 for UNICODEMGR but was told, rightfully so, that such a proposal needed to be a separate ACR. I am a bit concerned that especially since database names can be full paths we may rapidly exceed the limits) 

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