fix: change entity association in UserOptionController

[mikededo]

Description

• Fixed the Team-Repository association in the UserOptionController.
• Fixed the Organization-Team association in the UserOptionController.

Decisions taken

I opted to override the hashCode and equals methods using only the id
field. The reason is because if done properly, we should not have duplicated
entities and each entity is uniquely identified by the id field.

Closes #92

[plozanol]

Because id is a Integer object, you should first check if it isn't null. Also when overriding default behavior a test should be added to check consistency in this implementation.

If you want happy path and less boiler code, you could use lombok @EqualsAndHashCode annotation:
https://projectlombok.org/features/EqualsAndHashCode

[mikededo]

Regarding this, I get this warning:

Using @EqualsAndHashCode for JPA entities is not recommended. It can cause severe performance and memory consumption issues.

[mikededo]

Also, about the null subject, we have the Column annotation with the nullable = false. Furthermore, I think we could ensure more the type-safetiness using the @NotNull annotation.

[plozanol]

Regarding this, I get this warning:

Using @EqualsAndHashCode for JPA entities is not recommended. It can cause severe performance and memory consumption issues.

Yes, you are right, didn't remember that. Then hardcoded better to avoid performance issues. Go ahead with your implementation, seems good enough. It has some issues with JPA state entity lifecycle, but I think we shouldn't worry right now, as that inconsistencies didn't apply to our app.

https://vladmihalcea.com/how-to-implement-equals-and-hashcode-using-the-jpa-entity-identifier/

[plozanol]

Also, about the null subject, we have the Column annotation with the nullable = false. Furthermore, I think we could ensure more the type-safetiness using the @NotNull annotation.

Good point. I was thinking that it is better to make an issue to make all validation regards the entities level

[plozanol]

this isn't needed because the teams list is initialized always before the constructor call:
private List teams = new ArrayList<>();

We don't have any teams setter to be afraid (and we shouldn't) to avoid setTeams(null). In the future, if needed, a removeTeam method should be added.

[mikededo]

This is true if we are not using the builder function. Otherwise, the teams would be null.

[mikededo]

I do not understand this part:

We don't have any teams setter to be afraid (and we shouldn't) to avoid setTeams(null). In the future, if needed, a removeTeam method should be added.

Wasn't this what was previously implemented? I thought it is what you meant with the comment about bidirectional relations. What am I missing?

[plozanol]

To avoid duplicates, and this check, we could just select a collection that doesn't allow duplicates:
private Set teams = new LinkedHashSet<>();

[mikededo]

Sure, that's what I thought of using. However, is there any configuration with JPA to change? Or it will automatically manage it?