Client objects do not implement HashCode

[scarter93]

Describe the problem you'd like to have solved

Objects such as com.auth0.json.mgmt.Role do not implement java hashCode() and equals(). This causes unnecessary complexity when trying to compare equality or leverage intermediate data storage such as HashSet. For example, building a management portal where users can be added and removed from an application you want to compare equality of existing roles to available roles.

Describe the ideal solution

Client objects implement java hashCode() and equals().

Alternatives and current work-arounds

Create subclass and override hashCode() and equals() as needed.

Additional information, if any

[jimmyjames]

Thanks for the issue and context @scarter93! One thing we need to think about is how the domain objects represents both request and response payloads. So when considering equality, how we determine if two objects are equal when certain fields are only valid for either the request or response may be tricky to reason about as a consumer in some cases.

[scarter93]

@jimmyjames perhaps best way to solve that is with jsonviews and differing equality for those views, if possible. That way we could separate the equality and have clear and concise views for request/response.

Thoughts?

[jimmyjames]

@scarter93 using jsonviews is an interesting idea. Another alternative would be to break out separate classes specific to their operation (e.g., UserRequest and UserResponse). Either would be a pretty extensive change and would need to be considered for the next major version release. We'll think a bit more about potential implications of implementing equals and hashCode with the current design, but I think the following may demonstrate potential confusion points:

User userToCreate = new User();
userToCreate.setName("some name");
User createdUser = usersEntity.create(userToCreate).execute();

userToCreate.equals(createdUser); // would return false

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇‍♂️

[jimmyjames]

At this time implementing as the client objects are used as serialization objects for the request and response, implementing hashCode and equals isn't something we can do without introducing additional complexity or confusion. As discussed above it would be clearer to have separate transfer objects for both request and response, but that's a large change that even if done in a new major release would still potentially be a pretty big impact.

Going to close this issue, but I'll keep an eye on it for additional considerations for the next major.