HHH-19981 big change to handling of java.util.Date and friends #11417
Conversation
…type Date This fixes bugs in the metamodel where getJavaType() would return the wrong class even in the Persistence-standard metamodel. It's also a first step to fixing a bunch of other unsound things we do in the codebase.
though perhaps we could just remove this functionality
|
Thanks for your pull request! This pull request does not follow the contribution rules. Could you have a look? ❌ All commit messages should start with a JIRA issue key matching pattern › This message was automatically generated. |
|
Naturally,, it broke Envers. |
|
Why are we dramatically changing the behavior of something we are actively telling people to not use? |
As I said:
Whether people are using it or not, we still have these weird objects floating around in our code which aren't what they claim to be. Which prevents us from adding assertions based on the reified types of things. |
gavinking
changed the title
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| private <X> TemporalJavaType<X> forMissingPrecision(TypeConfiguration typeConfiguration) { | ||
| //noinspection unchecked,rawtypes | ||
| return (TemporalJavaType) this; | ||
| private TemporalJavaType<T> forMissingPrecision(TypeConfiguration typeConfiguration) { |
Check notice
Code scanning / CodeQL
Useless parameter Note
| } | ||
|
|
||
| protected <X> TemporalJavaType<X> forTimestampPrecision(TypeConfiguration typeConfiguration) { | ||
| protected TemporalJavaType<T> forTimestampPrecision(TypeConfiguration typeConfiguration) { |
Check notice
Code scanning / CodeQL
Useless parameter Note
| } | ||
|
|
||
| protected <X> TemporalJavaType<X> forDatePrecision(TypeConfiguration typeConfiguration) { | ||
| protected TemporalJavaType<T> forDatePrecision(TypeConfiguration typeConfiguration) { |
Check notice
Code scanning / CodeQL
Useless parameter Note
| } | ||
|
|
||
| protected <X> TemporalJavaType<X> forTimePrecision(TypeConfiguration typeConfiguration) { | ||
| protected TemporalJavaType<T> forTimePrecision(TypeConfiguration typeConfiguration) { |
Check notice
Code scanning / CodeQL
Useless parameter Note
JavaTypeRegistry and TypeConfiguration are now much cleaner + related minor cleanups in these classes
2 participants
Previously, the static metamodel would sometimes return objects of the wrong type. For example, an
Attribute<java.sql.Date>could returnjava.util.Date.class, which was not only wrong but also unsound. This happened because we haveJavaTypes which weren't actually modeling Java types. For example,JdbcTimestampTypewasn't a JavaType`.I believe that this is the original root cause of plenty of unsoundness and weirdness in our code base, so I have spent a day redoing it, so that fields of type
java.util.Dateare always represented byDateJavaType, and fields of typejava.sql.DatebyJdbcDateJavaType.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.