Refactor to always use JdbcColumnHandle.Builder instead of a constructor#18718
Refactor to always use JdbcColumnHandle.Builder instead of a constructor#18718dominikzalewski wants to merge 1 commit intotrinodb:masterfrom
Conversation
dominikzalewski
force-pushed
the
jdbc_column_handle_builder_refactor
branch
from
e5c5282 to
29b4c74
Compare
plugin/trino-base-jdbc/src/main/java/io/trino/plugin/jdbc/DefaultJdbcMetadata.java
Outdated
Show resolved
Hide resolved
plugin/trino-base-jdbc/src/test/java/io/trino/plugin/jdbc/JdbcColumnHandleUtil.java
Outdated
Show resolved
Hide resolved
plugin/trino-base-jdbc/src/test/java/io/trino/plugin/jdbc/JdbcColumnHandleUtil.java
Outdated
Show resolved
Hide resolved
dominikzalewski
force-pushed
the
jdbc_column_handle_builder_refactor
branch
from
29b4c74 to
80d1dee
Compare
plugin/trino-base-jdbc/src/main/java/io/trino/plugin/jdbc/JdbcColumnHandle.java
Outdated
Show resolved
Hide resolved
wendigo
left a comment
wendigo
left a comment
There was a problem hiding this comment.
LGTM % method arguments wrapping
plugin/trino-base-jdbc/src/main/java/io/trino/plugin/jdbc/BaseJdbcClient.java
Outdated
Show resolved
Hide resolved
dominikzalewski
force-pushed
the
jdbc_column_handle_builder_refactor
branch
from
80d1dee to
6df5803
Compare
Thanks for the review. I believe I have addressed every comment you made. |
hashhar
left a comment
hashhar
left a comment
There was a problem hiding this comment.
No opinions on this one. I don't see apparent benefits since we trade a constructor for a static method with same number of arguments.
LGTM % how do we prevent new usages of the constructor from appearing?
|
@hashhar do you think that we should make constructor |
|
I don't see the benefit of doing that - i.e. why is this change useful? There will always be code which needs to create |
|
@hashhar this is required for the upcoming change that will introduce new field (optional) on the JdbcColumnHandle. Hence the builder usage. |
It'll be needed to be done if we want to avoid the bug we want to fix from being reintroduced without noticing. |
Can you share the link of the bug? |
| + jdbcTypeHandle.getRetainedSizeInBytes(); | ||
| } | ||
|
|
||
| public static JdbcColumnHandle createJdbcColumnHandle(String columnName, JdbcTypeHandle jdbcTypeHandle, Type columnType) |
There was a problem hiding this comment.
Refactor to always use JdbcColumnHandle.Builder instead of a constructor
createJdbcColumnHandle method defeats the purpose of this commit. What is the difference between factory method and constructor? I would inline this method.
|
#18924 is already merged. Do we still need this PR? |
|
Sorry, we don't need it any more. My fault leaving the trash behind. Closed now. |
5 participants
Description
Refactor to always use JdbcColumnHandle.Builder instead of a constructor. This is a prerequisite change for a bugfix.
Additional context and related issues
Release notes
(X) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text: