Unexpected dirty checking behavior on collections of POJOs mapped with JsonBinaryType

[mojgh]

Description

When reading entities with collections of POJOs such as TestEntity (see Example 1), updates are performed on the database without the objects being changed.

Example 1

@TypeDefs({
        @TypeDef(name = "jsonb", typeClass = JsonBinaryType.class)
})
@Entity
public class TestEntity {

    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Id
    public int id;

    @Type(type = "jsonb")
    public Collection<TestElement> testElements;


    public static class TestElement implements Serializable {

        static final long serialVersionUID = -8485895696327472738L;

        public String testProperty;

    }

}

Analysis

It appears as if the dirty check on JsonBinaryType properties for collections of POJOs does no longer work as expected.
The problem occurs since [commit-1]. This commit introduces a new dirty checking behavior for JsonBinaryType, when used with collections:

public boolean areEqual(Object one, Object another) {
// ...
	if (one instanceof Collection && another instanceof Collection) {
		return Objects.equals(one, another);
	}

JsonTypeDescriptor

I would not expect the usage of java.lang.Object#equals at this point. In my understanding it creates an inconsistency compared to the dirty checking behavior used for non-collection types.
The recursive field by field comparison before [commit-1] is appropriate in my opinion.

Workaround

Downgrade to the version before [commit-1]: version 2.4.2.

Links

commit-1

[vladmihalcea]

Thanks for the analysis. It would be great if you proposed a Pull Request as well. I'll review it once it's ready.

Also, you need to add a replicating test case that proves the issue as well.

[mojgh]

A small project to prove the problem: hibernate_types_138.zip

[vladmihalcea]

I think it's better to fork the project and create a replicating test case from an existing test case. This way, the test can prevent the issue from occurring in future as well.

[vladmihalcea]

This commit proves that everything works as expected. The only case where I found the issue that you are describing is if you are using a Collection of Objects that don't implement equals or hashCode based on the inner properties, so the default java.lang.Object implementations are used.

[cosminseceleanu]

@vladmihalcea after 4 days of debugging and a lot of logs(including a hot fix) I found that my issue was caused by a similar case.

The only case where I found the issue that you are describing is if you are using a Collection of Objects that don't implement equals or hashCode

Is this documented somewhere? Thanks in advance

[vladmihalcea]

@cosminseceleanu I think it's useful to add it to the README.md doc. Send me a Pull Request with the change. Thanks.

[cosminseceleanu]

@vladmihalcea I updated the docs. Please review.

Off topic: I think this project is missing a contribution guide 😃

[vladmihalcea]

Thanks. I'll review it when I have some time. It would be great if there were a Contribution Guide too. You can supply one if you like.

[62mkv]

another half a day spent on hair-pulling due to this issue.. :)

I decided to bump many things at once - my bad. eventually settled down on this problem. Works fine with com.vladmihalcea:hibernate-types-52:2.9.0, dirty UPDATES manifest themselves with 2.10.0.

However, I still can't understand what is the root cause, will have to check further. Right now it seems that all of the following:

• entity itself
• POJO that is wrapped in JSON
• and types used in collections of this POJO,
  all of it has equals and hashCode implementation (entity - the one suggested by JPABuddy IntelliJ plugin, the other two - implemented with Lombok)

And no warnings are given in 2.10.1 version either, I guess because validatePropertyType only checks if the annotated field type is a Collection (which it isn't, in my case) .

I'll see if I can submit a reproducible test project soon.