We are using adk 5.0.23 but after a cursory look at the code it looks like the bug is still present in some form in 5.4, seemingly only affecting equals().
In rare cases, generated equals() and hashcode() entity methods can invoke equals and hashcode of a lazy-loaded member, which cause excessive database load and extremely poor performances, especially during cache lookups.
We have <one-to-one> fields defined in a few entities with unique="true", and it seems that the unique attribute is the culprit, as it automatically appends a check on these lazy loaded entities. Right now we can use hashKey="false" and ignore the xsd validation error but it's neither clean nor future-proof.
In 5.4 I suppose we can try to use equalsInclude="false" instead, but again apparently this doesn't pass the 5.4 xsd validation.
Hello,
We are using adk 5.0.23 but after a cursory look at the code it looks like the bug is still present in some form in 5.4, seemingly only affecting
equals(). In rare cases, generatedequals()andhashcode()entity methods can invokeequalsandhashcodeof a lazy-loaded member, which cause excessive database load and extremely poor performances, especially during cache lookups.We have
<one-to-one>fields defined in a few entities withunique="true", and it seems that theuniqueattribute is the culprit, as it automatically appends a check on these lazy loaded entities. Right now we can usehashKey="false"and ignore the xsd validation error but it's neither clean nor future-proof.In 5.4 I suppose we can try to use
equalsInclude="false"instead, but again apparently this doesn't pass the 5.4 xsd validation.