morningman opened a new pull request, #68968:
URL: https://github.com/apache/doris/pull/68968

   ### What problem does this PR solve?
   
   Issue Number: None
   
   Related PR: #62183, #55651, #68786
   
   Problem Summary:
   
   **In short.** A JDBC catalog that points at another Doris shows the remote 
VARBINARY columns as STRING (`text`). This PR maps them to VARBINARY again, as 
the fe-core JDBC client and branch-4.x do. It is not a port of a branch-4.x 
change; it came up while comparing the binary type mappings of the two branches.
   
   **Background.** When the JDBC connector became a plugin (#62183), the Doris 
dialect of `JdbcMySQLConnectorClient` mapped a remote `VARBINARY` to `STRING`. 
The fe-core `JdbcMySQLClient` it replaced, and branch-4.x, map it to 
`VARBINARY` with the column size the remote reports (#55651). For every other 
JDBC source, binary types already map to `VARBINARY` regardless of the 
deprecated `enable.mapping.*` flags (#68786, pinned by 
`JdbcLogicalTypeMappingTest`). A remote Doris exposes VARBINARY through views 
and external tables.
   
   **The problem, and what it cost.**
   
   | A JDBC catalog connected to the local Doris, reading a view with 
`cast('abc' as varbinary(16))` | master | with this PR |
   |---|---|---|
   | `DESC` | `b text` | `b varbinary(65535)` (the length the remote reports 
through the JDBC metadata) |
   | `SELECT b` | the value as a string | `0x616263`, the remote bytes; 
`hex(b)` = `616263` |
   
   **How this PR fixes it.** The Doris dialect maps `VARBINARY` to `VARBINARY`, 
taking the length from the type name when it carries one and otherwise from the 
column size, like the dialect's `VARCHAR` branch and the fe-core client.
   
   **Results.**
   
   - FE UT: 
`JdbcLogicalTypeMappingTest#remoteDorisVarbinaryKeepsBytesAndDeclaredLength` 
fails without the fix (STRING) and passes with it; all fe-connector-jdbc tests 
(250) pass.
   - Regression: `test_doris_jdbc_catalog_varbinary` connects a JDBC catalog to 
the local Doris and reads a view with a VARBINARY column. With the previous 
plugin the column is described as `text` and the suite fails; with this PR it 
passes.
   
   ### Release note
   
   A JDBC catalog connected to another Doris shows the remote VARBINARY columns 
as VARBINARY instead of STRING.
   
   ### Check List (For Author)
   
   - Test <!-- At least one of them must be included. -->
       - [x] Regression test
           - `test_doris_jdbc_catalog_varbinary` (JDBC catalog over the local 
Doris); the `.out` was generated by the script.
       - [x] Unit Test
           - 
`JdbcLogicalTypeMappingTest#remoteDorisVarbinaryKeepsBytesAndDeclaredLength`; 
fe-connector-jdbc tests (250) pass.
       - [ ] Manual test (add detailed scripts or steps below)
       - [ ] No need to test or manual test. Explain why:
           - [ ] This is a refactor/code format and no logic has been changed.
           - [ ] Previous test can cover this change.
           - [ ] No code files have been changed.
           - [ ] Other reason <!-- Add your reason?  -->
   
   - Behavior changed:
       - [ ] No.
       - [x] Yes. <!-- Explain the behavior change -->
           - Remote Doris VARBINARY columns map to VARBINARY instead of STRING.
   
   - Does this need documentation?
       - [x] No.
       - [ ] Yes. <!-- Add document PR link here. eg: 
https://github.com/apache/doris-website/pull/1214 -->
   
   ### Check List (For Reviewer who merge this PR)
   
   - [ ] Confirm the release note
   - [ ] Confirm test cases
   - [ ] Confirm document
   - [ ] Add branch pick label <!-- Add branch pick label that this PR should 
merge into -->
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to