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

Work out what to do with embeddable types without a proper equals-hashCode implementation in updatable entity views #667

Closed
beikov opened this issue Sep 30, 2018 · 4 comments

Comments

@beikov
Copy link
Member

@beikov beikov commented Sep 30, 2018

The problem is that updatable entity view objects are de-duplicated i.e. when joining collections, the result list tuples are flattened. The flattening can't happen unfortunately if there is an embeddable involved that doesn't implement equals-hashCode properly. There are probably some other collection duplication issues with that.
Since the symptom(exception that a parent was already set, duplicate elements in collections) says nothing about the actual cause, we have to check that somehow at validation time.
IMO we should require something explicit from the user to make sure he understands the implicaiton of using an embeddable type in an entity view.

Thoughts anyone?

@beikov
Copy link
Member Author

@beikov beikov commented Sep 30, 2018

Bytecode analysis is pretty fragile so I don't think this is a good idea. I was thinking about instantiating embeddables with some values and invoking the actualy equals hashCode methods for a sanity check. This seems to be the least fragile and can be done at startup.

Loading

@jwgmeligmeyling
Copy link
Collaborator

@jwgmeligmeyling jwgmeligmeyling commented Sep 30, 2018

Can't you extract the embeddable tuple values for equality? I.e. a map from <SingularAttribute, Object>? Potentially using the metamodel's getJavaMember method?

Loading

@beikov
Copy link
Member Author

@beikov beikov commented Sep 30, 2018

The main problem is that there is no efficient way to construct a tuple from an embeddable and this would require many changes in the code that handles collections in entity views. I'd rather have users think twice before using embeddable types in entity views than give a user a performance hit. It would be better to use a flat view instead of the embeddable most of the time anyway.

Loading

@beikov
Copy link
Member Author

@beikov beikov commented Oct 11, 2018

This was fixed by checking the implementation through invocation with test instances

Loading

@beikov beikov closed this Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants