-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HHH-18446 Cannot use @JdbcTypeCode(SqlTypes.LONG32VARBINARY) on field with null value #9103
base: main
Are you sure you want to change the base?
Conversation
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
@@ -85,12 +85,12 @@ public static void prime(BaselineTarget target) { | |||
target.addDescriptor( BinaryJdbcType.INSTANCE ); | |||
target.addDescriptor( VarbinaryJdbcType.INSTANCE ); | |||
target.addDescriptor( LongVarbinaryJdbcType.INSTANCE ); | |||
target.addDescriptor( new LongVarbinaryJdbcType(SqlTypes.LONG32VARBINARY) ); | |||
target.addDescriptor( new LongVarbinaryJdbcType(SqlTypes.LONGVARBINARY, SqlTypes.LONG32VARBINARY) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cigaly this looks fine, but would a simpler (and maybe slightly better) change be to just register the type twice, something like:
target.addDescriptor( new LongVarbinaryJdbcType(SqlTypes.SqlTypes.LONG32VARBINARY) );
target.addDescriptor( SqlTypes.LONG32VARBINARY, new LongVarbinaryJdbcType(SqlTypes.LONG32VARBINARY) );
(I'm not sure, just asking.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, no, wait, scratch that, I misunderstood.
public int getDefaultSqlTypeCode() { | ||
return defaultSqlTypeCode; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I understand, I would say we don't need to parameterize the class by defaultSqlTypeCode
, we can just hardcode this method to return Types.LONGVARCHAR
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that this is, at least, partially correct. Only it seems that JDBC type code should be fixed, and default SQL code changeable, but I will check that again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one that is used for binding to null
values to JDBC is that one that needs to be hardcoded. The one used for registration and for schema export is the one that's parameterized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess now that is exactly this
Jira issue HHH-18446
Fixing problem by adding (configurable) default SQL type code to LongVarbinaryJdbcType abd LongVarcharJdbcType
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.