| Wow, this log message is becoming a novel! Or a short-story at the least  There is simply a lot of information to convey here. More than is reasonable in a log message. That is why I asked Vlad to make sure we cover this in the documentation. The log message can certainly be improved; it's merely a question of how much is enough info without being too much... 1) Your issue really is not the JavaTypeDescriptor relying on equals/hashCode. Your issue is which JavaTypeDescriptor is used (and therefore which form is checked). Specifically you want a completely different algorithm to check equals and hashCode. Currently we check the "domain side" values against each other, because honestly that is the most reasonable. You instead want us to (a) convert that "domain side" value (SomeClass) into the "database side" value (String) and then compare those. For most people at least, the conversion here is very undesirable, especially when using AttributeConverter. Personally this was my intention with allowing a new @Comparator to be part of the equation here (as mentioned on
HHH-11391 Open ) 2) In retrospect I am not convinced this should be WARN at all. This feels more like a DEBUG message. It helps the developer debug why something is going wrong as opposed to something we have to scream at the user's face. 3) You seem to have looked in the code, so I'm surprised you did not see the check for @org.hibernate.annotations.Immutable along the lines you describe. I do plan on looking at other "hints" (again see
HHH-11391 Open ). Just so you realize however, these are hints on the Java type.. in other words, you would be annotating SomeClass. Annotating this on the converted attribute is never going to be supported - it leaves open the possibility of inconsistent definitions[1]. |