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.
The text was updated successfully, but these errors were encountered:
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.
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.