@CustomType #4266
Replies: 8 comments 38 replies
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
What would be the solution for automatically applying a custom type to a given class? We used to have Thinking about it, shouldn't the solution be similar to |
Beta Was this translation helpful? Give feedback.
-
|
Depending on exactly what the custom UserType did...
|
Beta Was this translation helpful? Give feedback.
-
|
@sebersole I don't think I like this |
Beta Was this translation helpful? Give feedback.
-
|
No I like it. It helps solve the fugly annotations-dont-have-inheritance-so-we-need-to-wrap-the-annotation-we-are-interested-in-within-other-annotations. In other words, I find this nicer than at least from the perspective of implementing support for it. In my opinion its arguable which is better from a user perspective and some will prefer one while others prefer the other. But the one argument for it as-is is consistency with JPA e.g. with And keep in mind, its not just
|
Beta Was this translation helpful? Give feedback.
-
Yes, so that will help with the sane cases. If users want to use raw types, they still can use the attribute/path approach |
Beta Was this translation helpful? Give feedback.
-
Yes. But that was just copy/paste from the form defining attributeName as well. Yes, if there is just one value I'd use value. Ofc then your risk the problem of needing to add an attribute later and then value is (most likely) no longer the right name. But I agree in that I would do the same with just one attribute |
Beta Was this translation helpful? Give feedback.
-
Its actually possible to understand what you are saying and yet still disagree with you ;) I understand exactly what you are saying. Personally I hate these TYPE_USE annotations generally speaking. I think they make code way harder to read. But its an elegant solution for sure |
Beta Was this translation helpful? Give feedback.
-
Minor point, but there will never be such a place for a collection-id. |
Beta Was this translation helpful? Give feedback.
-
|
Nor ANY mappings |
Beta Was this translation helpful? Give feedback.
-
|
As I played with prototyping this (and porting tests, especially) I wonder if it is worthwhile to still provide a As well as adjusting Coming back to the enum point.. as I mentioned, I think it depends on what we want to support. 2 things in particular I'd like to support that we need to consider here:
And of course it depends how we want to support those. For discriminator, e.g, do we add a For overrides, the difference comes back to needing to supply open-ended values (i.e. actual attribute names) Don't know the answers yet; just some thoughts that ran through my head as I started implementing this |
Beta Was this translation helpful? Give feedback.
-
|
My only concern with stuff like |
Beta Was this translation helpful? Give feedback.
-
I'd limit those to just package and class and say they are global. It's really just an easy form of using TypeContributor |
Beta Was this translation helpful? Give feedback.
-
|
If it is just "sugar", I'd opt to not having the annotation at all and require a TypeContributor instead. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it is "sugar". But sugar that is very useful for tests. Unless we add something like @domainmodel( ... typeContributors=... ) Which is fine as well. |
Beta Was this translation helpful? Give feedback.
-
|
My concern there though is that if our tests need it, it is likely users will also. But I am fine aggressively and proactively defining what we want here and maybe needing to go back and add something like this if enough users complain |
Beta Was this translation helpful? Give feedback.
-
|
So I changed my mind a bit. I (and I think all of us) would preferred annotations to be able to implement a common interface, but it ofc does not. So the next best thing is to use the nested annotation approach. We can look at the type-use approach later as a possible improvement. So I'll do: Though, even this might be better to allow for adding addition mapping details |
Beta Was this translation helpful? Give feedback.
-
|
I'll send a PR when I am done, so we can fix any of this we need to later, but I am wondering if anyone has improvements to these javadocs so far: |
Beta Was this translation helpful? Give feedback.
-
|
LGTM. It's interesting, because I think the use case seems somewhat similar to what we have in Hibernate Search, so I'll go ahead and suggest an API similar to what we did in Hibernate Search 6. If that's not relevant, that's fine; I just want to bring it to your attention in case you like it. I'm assuming that all those options you are providing ( In Hibernate Search, we have a concept of "bridge" and "binder". Both are user-implemented callbacks:
What I'm suggesting is, instead of exposing lots of options in your annotations, you could just provide some "binder" API: @BasicBinding(binder = MyBinder.class)
MyType myProperty;public class MyBinder implements CustomTypeBinder {
public void bind(CustomTypeBindingContext context) {
context.mutabilityPlan( MutabilityPlan.SOMETHING );
context.jdbcTypeDescriptor( SomeJdbcTypeDescriptor.INSTANCE );
context.customType( new MyCustomType() );
}
private static class MyCustomType implements CustomType {
// ...
}
}This gives a lot of flexibility. The binder could inspect the property and assign a different custom type depending on the property type, for example: public class MyBinder implements CustomTypeBinder {
public void bind(CustomTypeBindingContext context) {
if ( context.propertyRawType() == String.class ) {
context.mutabilityPlan( MutabilityPlan.SOMETHING );
context.jdbcTypeDescriptor( SomeJdbcTypeDescriptor.INSTANCE );
context.customType( new MyCustomType() );
}
else {
context.mutabilityPlan( MutabilityPlan.SOMETHING_ELSE );
context.jdbcTypeDescriptor( SomeOtherJdbcTypeDescriptor.INSTANCE );
context.customType( new MyOtherCustomType() );
}
}
private static class MyCustomType implements CustomType {
// ...
}
private static class MyOtherCustomType implements CustomType {
// ...
}
}Another advantage, though it's in no way necessary if you don't like it, is that you're able to move operations out of Here's the documentation of binders/bridges in Hibernate Search, though I don't think it will be very useful to you, since the |
Beta Was this translation helpful? Give feedback.
-
|
It's a bit difference. All of them affect the resolution of mapping details during boot. At runtime they are all used when actually reading (not yet writing always) values of the particular mapping |
Beta Was this translation helpful? Give feedback.
-
|
Going to make a change as I got into implementing this... First, I am going to drop:
Then define And then: |
Beta Was this translation helpful? Give feedback.
-
TLDR; Introduce
@CustomTypeas a type-safe replacement for@Type.https://hibernate.atlassian.net/browse/HHH-14856
We've had a few discussions now about wanting to move away from Type determination being based on Strings and to define a more type-safe way to accomplish that.
I propose the following annotation:
With regard to
#attributeName, it was suggested by @beikov and I think its a great idea. Rather than needing additional annotations such as@MapKeyCustomType, etc we can just have a single annotation and specify what the type applies to. This follows the pattern used by JPA so that's good(ish)I also propose that we drop
@Type,@MapKeyType,@TypeDef,@TypeDefsas part of this work. We have better ways for users to accomplish these, so there is good migration story. KeepingUserTypeand providing@CustomTypecovers the remaining cases where people want/have to continue to use UserType impls. And it gets us out of the String-based resolution at all. Well, from annotations at least.Beta Was this translation helpful? Give feedback.
All reactions