You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing #12985, I've discovered a glitch regarding forced types, which hasn't appeared yet with the Maven plugin, but does with the new gradle plugin.
Despite forced types being applied correctly, this is being logged:
Unused forced type : <priority>0</priority><name>VARCHAR(10)</name><autoConverter>true</autoConverter><includeExpression>J</includeExpression><nullability>ALL</nullability><objectType>ALL</objectType>
Unused forced type : <priority>0</priority><name>BIGINT</name><autoConverter>true</autoConverter><includeExpression>K</includeExpression><nullability>ALL</nullability><objectType>ALL</objectType>
The reason is because we add the forced types to the AbstractDatabase.unusedForcedTypes hash set, and then modify them on some occasions, e.g. to set autoConverter to true. Obviously, that's forbidden by the HashSet contract, because now, the hashCode (and equals behaviour) changes.
A workaround would be to set autoConverter = true, but similar things happen when using the deprecated expression value, for example, which is copied to includeExpression.
There are a few ways to fix this:
Fix equals() and hashCode(), making them more intelligent (hard to check)
Use an IdentityHashMap instead (possibly regressing in the future, when we create clones of ForcedType instances, which we currently don't do)
Delay initialisation of the HashSet until all the ForcedType values have been patched (probably the best solution here)
Remove and re-add any ForcedType that is modified (hard to remember)
The text was updated successfully, but these errors were encountered:
While testing #12985, I've discovered a glitch regarding forced types, which hasn't appeared yet with the Maven plugin, but does with the new gradle plugin.
Despite forced types being applied correctly, this is being logged:
The reason is because we add the forced types to the
AbstractDatabase.unusedForcedTypes
hash set, and then modify them on some occasions, e.g. to setautoConverter
totrue
. Obviously, that's forbidden by theHashSet
contract, because now, the hashCode (and equals behaviour) changes.A workaround would be to set
autoConverter = true
, but similar things happen when using the deprecatedexpression
value, for example, which is copied toincludeExpression
.There are a few ways to fix this:
equals()
andhashCode()
, making them more intelligent (hard to check)IdentityHashMap
instead (possibly regressing in the future, when we create clones ofForcedType
instances, which we currently don't do)HashSet
until all theForcedType
values have been patched (probably the best solution here)ForcedType
that is modified (hard to remember)The text was updated successfully, but these errors were encountered: