Skip to content

DATAJDBC-327 - Adds support for conversion to JdbcTypeAware and storing byte[] as binary. #123

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

Closed
wants to merge 4 commits into from

Conversation

schauder
Copy link
Contributor

@schauder schauder commented Mar 7, 2019

Some JDBC drivers depend on correct explicit type information in order to pass on parameters to the database.
So far CustomConversion had no way to provide that information.
With this change one can use @WritingConverter that converts to JdbcTypeAware in order to provide that information.

byte[] now also get stored as BINARY.

See also: DATAJDBC-239.

Copy link
Member

@mp911de mp911de left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments. Looks pretty decent and I think we should add some more Javadoc along with some assertions.

@@ -292,15 +288,18 @@ public long count(Class<?> domainType) {
return result;
}

private <S, T> MapSqlParameterSource getPropertyMap(S instance, RelationalPersistentEntity<S> persistentEntity,
String prefix) {
private <S, T> MapSqlParameterSource getParameterSource(S instance, RelationalPersistentEntity<S> persistentEntity,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: How about Predicate< RelationalPersistentProperty> instead of skipId?

* @since 1.1
*/
@Value(staticConstructor = "of")
public class JdbcTypeAware {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about naming this type JdbcValue?

* needs to be provided anyway, mostly for providing backward compatibility. Calling it will result in an exception.
* The features normally supported by a {@link JdbcTypeFactory} will not work.
*/
JdbcTypeFactory DUMMY_JDBC_TYPE_FACTORY = value -> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about naming this one SIMPLE? From a design perspective, we could turn the field into a static interface method to align with our API style.

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 don't like SIMPLE because it is kind of less than simple: Not really working. How about UNSUPPORTED?

* @param value the value to be converted. Must not be {@literal null}.
* @return an {@link Array}. Guaranteed to be not {@literal null}.
*/
Array createArray(Object[] value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very nice that we do not declare SQLException 👍

@@ -0,0 +1,7 @@
/**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Package declarations do not get author tags.

/**
* In PostrgreSQL this fails if a simple converter like the following is used.
*
* <pre>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: How about <pre class="code">? This makes formatting a bit simpler.

@@ -193,6 +193,30 @@ public Object writeValue(@Nullable Object value, TypeInformation<?> type) {
return conversionService.convert(value, rawType);
}


@Override
public boolean canWriteValue(Object value, TypeInformation<?> type) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep this method on JDBC level. The underlying assumption is that a module using the converter is able to persist entities as values.

From how the method is used, I would even suggest to keep it private and consider public exposure at a later time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main implementation is in the BasicRelationalConverter based on the conversions service.

If we don't want to expose it there we could drop it completely and rely on exception handling, possibly even caching failures.

Not sure that is a good way to do it though.
I'm also not sure I understood your comment about the underlying assumption.

}

if (componentType == Byte.class) {
Byte[] boxedBytes = (Byte[]) convertedValue;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's extract the code into a package-private utility (ArrayUtil.toPrimitive(…)) or something like that.


private final JdbcOperations operations;

public DefaultJdbcTypeFactory(JdbcOperations operations) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Assertion for Non-null.

…ng byte[] as binary.

Some JDBC drivers depend on correct explicit type information in order to pass on parameters to the database.
So far CustomConversion had no way to provide that information.
With this change one can use @WritingConverter that converts to JdbcTypeAware in order to provide that information.

byte[] now also get stored as BINARY.

See also: DATAJDBC-239.
@schauder schauder force-pushed the issue/DATAJDBC-327 branch from 4afac46 to 9054265 Compare March 11, 2019 11:27
@schauder schauder force-pushed the issue/DATAJDBC-327 branch from 9054265 to c6871ca Compare March 11, 2019 14:10
@schauder
Copy link
Contributor Author

I fixed all the mentioned issues.

mp911de pushed a commit that referenced this pull request Mar 12, 2019
…[] as binary.

Some JDBC drivers depend on correct explicit type information in order to pass on parameters to the database.
So far CustomConversion had no way to provide that information.
With this change one can use @WritingConverter that converts to JdbcTypeAware in order to provide that information.

byte[] now also get stored as BINARY.

Original pull request: #123.
mp911de pushed a commit that referenced this pull request Mar 12, 2019
Removed author tag for package-info.java

Original pull request: #123.
mp911de added a commit that referenced this pull request Mar 12, 2019
Extend Javadoc. Reorder constructors in the order of their parameter number. Add missing assertions. Introduce utility to create predicates. Remove unused fields. Add since tags. Reformat.

Original pull request: #123.
@mp911de
Copy link
Member

mp911de commented Mar 12, 2019

That's merged and polished now.

@mp911de mp911de closed this Mar 12, 2019
@mp911de mp911de deleted the issue/DATAJDBC-327 branch March 12, 2019 13:07
THD-Thomas-Lang pushed a commit to THD-Thomas-Lang/spring-data-jdbc that referenced this pull request Apr 12, 2019
…[] as binary.

Some JDBC drivers depend on correct explicit type information in order to pass on parameters to the database.
So far CustomConversion had no way to provide that information.
With this change one can use @WritingConverter that converts to JdbcTypeAware in order to provide that information.

byte[] now also get stored as BINARY.

Original pull request: spring-projects#123.
THD-Thomas-Lang pushed a commit to THD-Thomas-Lang/spring-data-jdbc that referenced this pull request Apr 12, 2019
Removed author tag for package-info.java

Original pull request: spring-projects#123.
THD-Thomas-Lang pushed a commit to THD-Thomas-Lang/spring-data-jdbc that referenced this pull request Apr 12, 2019
Extend Javadoc. Reorder constructors in the order of their parameter number. Add missing assertions. Introduce utility to create predicates. Remove unused fields. Add since tags. Reformat.

Original pull request: spring-projects#123.
mp911de pushed a commit that referenced this pull request Feb 21, 2022
mp911de added a commit that referenced this pull request Feb 21, 2022
Add extension for UpdateTableSpec.table. Add tests. Formatting.

Original pull request: #123.
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