Skip to content
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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

cigaly
Copy link
Contributor

@cigaly cigaly commented Oct 17, 2024

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.


@hibernate-github-bot
Copy link

hibernate-github-bot bot commented Oct 17, 2024

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

@cigaly cigaly changed the title HHH-18446 HHH-18446 Cannot use @JdbcTypeCode(SqlTypes.LONG32VARBINARY) on field with null value Oct 17, 2024
@@ -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) );
Copy link
Member

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.)

Copy link
Member

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.

Comment on lines 50 to 45
public int getDefaultSqlTypeCode() {
return defaultSqlTypeCode;
}
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants