Fix id type wrong due to no sorted methods from Class.getMethods#620
Fix id type wrong due to no sorted methods from Class.getMethods#620hugogu wants to merge 1 commit intoyahoo:masterfrom
Conversation
|
Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! 😄 |
aklish
left a comment
There was a problem hiding this comment.
Thanks for the PR. The change seems reasonable. Can you add a unit test case so we don't have a regression? Thanks!
| String fieldName = getFieldName(fieldOrMethod); | ||
| Class<?> fieldType = getFieldType(fieldOrMethod); | ||
|
|
||
| if (idType != null && fieldType.isAssignableFrom(idType)) { |
There was a problem hiding this comment.
If ordering is undefined in the OpenJDK, how can we be sure that we always want the first idType?
This looks like it will cause us to only bind the first field or method annotated with @Id we find and not necessarily the @Id that is closest to the class we are binding.
Also, what does it mean for a JPA annotated bean to have more than 1 field annotated with @Id?
DennisMcWherter
left a comment
There was a problem hiding this comment.
Reviewing the JPA spec (warning: Oracle PDF link), it may be worth considering the information in Section 2.4. Id's are actually a bit complicated and we have not implemented the full spec here (mainly due to lack of practical use rather than lack of will). Namely, behavior related to @IdClass is likely not spec compliant today. However, this seems mostly related to information about derived entities (section 2.4.1).
@hugogu can you give an example of what exactly this is trying to solve?
If you are extending and using a @MappedSuperclass (this is distinct from a section 2.4.1 derived class), section 2.11 demonstrates it is not explicitly supported to override attributes through typical Java inheritance (and in fact, may be disallowed):
When applied to the subclasses, the inherited mappings will apply in the context of the subclass tables. Mapping information can be overridden in such subclasses by using the AttributeOverride and AssociationOverride annotations or corresponding XML elements.
In short, it looks like you would want to use @AttributeOverride to make this stick.
Now, to be clear, I am pretty sure we do not support this today. However, implementing the override in the EntityBinding should be a straightforward task.
|
@clayreimann @DennisMcWherter , Thank you all for the review comments. It sounds like there is a more appropriate way to achieve the same purpose. I'll do some more investigation as per your suggestions and get back with more details. Hugo |
|
Thanks! Looking forward to seeing the update! :) |
|
1:When MyEntity.class extend AbstractPersistable . This problem while reshow. |
|
Could you provide a small project that highlights this issue? That way we can experiment and write tests to ensure we don’t break this use case in the future.
|
The Class.getMethods returns undetermined ordering in OpenJDK which may break the idType.