Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow subtype equality in EntityView equals-hashCode implementation #430

Closed
Mobe91 opened this issue Aug 2, 2017 · 4 comments

Comments

@Mobe91
Copy link
Contributor

commented Aug 2, 2017

At the moment, the equals-hashCode implementation in the generated entity view proxies require type equality which can be hindering in many usage scenarios. Therefore the implementation should be changed to equality in case of compatible subtypes with equal IDs.

@beikov

This comment has been minimized.

Copy link
Member

commented Aug 2, 2017

Now if you have two entity view V1 and V2, where V2 extends V1, calling V1.equals(V2) would return true but V2.equals(V1) would return false which kind of breaks the general equals-hashCode contract.

I think a better approach is to test for entity type equality. Since both V1 and V2 are views on the entity type E we could determine compatibility by that fact. What do you say?

@beikov beikov added this to the 1.2.0 milestone Aug 2, 2017

@Mobe91

This comment has been minimized.

Copy link
Contributor Author

commented Aug 2, 2017

True, that's a problem.
Using entity type equality sounds good.

@beikov beikov added this to TODO in 1.2.0.Alpha4 Aug 14, 2017

@beikov

This comment has been minimized.

Copy link
Member

commented Sep 25, 2017

I'm starting to think that #440 is the more proper solution to the underlying problem. An explicit conversion would make the intent much clearer. What do you say? Would that be sufficient or are there cases where a conversion would be unpleasant?
If you have hash maps or set, you could work with a value wrapper that implements the equality checking based on what you would like, the entity type and the id, but I'm simply not sure it's such a good idea to always do it like this. Maybe you can convince me? :)

@beikov

This comment has been minimized.

Copy link
Member

commented Oct 16, 2017

Ok, the argument, that entity views are just a fragment of an entity which shouldn't change the identity regarding equals-hashCode convinced me. I will implement that in an upcoming version.

@beikov beikov moved this from TODO to In Progress in 1.2.0.Alpha4 Nov 7, 2017

beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 7, 2017
Blazebit#430 - Introduce JPA managed type access to EntityViewProxy a…
…nd move to SPI. Base equals on JPA managed type to fix Blazebit#430

@beikov beikov moved this from In Progress to Done in 1.2.0.Alpha4 Nov 7, 2017

beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 7, 2017
Blazebit#430 - Introduce JPA managed type access to EntityViewProxy a…
…nd move to SPI. Base equals on JPA managed type to fix Blazebit#430
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 7, 2017
Blazebit#430 - Introduce JPA managed type access to EntityViewProxy a…
…nd move to SPI. Base equals on JPA managed type to fix Blazebit#430

@beikov beikov closed this in 6e217d6 Nov 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.