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
Record like property access support #2994
Conversation
putInNegativeCache(cacheKey); | ||
return null; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I unwound the nesting of the exceptions - there was no need for it and I think this is clearer code
Records cannot extend any class - so we need only check the root class for a publicly declared method with the propertyName | ||
*/ | ||
private Method findRecordMethod(CacheKey cacheKey, Class<?> rootClass, String methodName) throws NoSuchMethodException { | ||
if (Modifier.isPublic(rootClass.getModifiers())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Records are also final
. findRecordMethod
should be restricted to records or other final
classes.
if (Modifier.isPublic(rootClass.getModifiers()) && Modifier.isFinal(rootClass.getModifiers())) {
* smells like one and that's enough really. Its public, not derived from another | ||
* class and has a public method named after a property | ||
*/ | ||
public class RecordLikeClass { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this public final class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have decided we will look up record like methods - not truly final ones like records are.
# Conflicts: # src/main/java/graphql/schema/PropertyFetchingImpl.java
MethodFinder methodFinder = (rootClass, methodName) -> findRecordMethod(cacheKey, rootClass, methodName); | ||
return getPropertyViaRecordMethod(object, propertyName, methodFinder, singleArgumentValue); | ||
} catch (NoSuchMethodException ignored) { | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I unwound the nesting because I think this reads better than try
inside try
inside try
if (!recordLikeMethods.isEmpty()) { | ||
return recordLikeMethods.get(0); | ||
} | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Support in the lambda code to find recordLike()
methods
|
||
public String recordLike() { | ||
return "recordLike"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IN theory this is possible - stupid but possible - in the old days the getter would be found so this shows that this still happens. eg record getters are looked up after pojo getters
package graphql.schema.somepackage; | ||
|
||
public class RecordLikeTwoClassesDown extends RecordLikeClass { | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hence derivation works with record like methods
Moved record like to the front of the search pattern
This changes the
PropertyDataFetcher
so that support Javarecord
like naming.eg
object.propertyName()
method namingWhile the code here is not specific to record classes only - it will work with them and with any class that uses
propertyName()
method naming#2994 has been updated
I have decided to change the strategy - we will look for "direct property" methods first and then getters
So given a field
issues
- then we will look forissues()
first and then if it fails to find that it will look forgetissues
orgetIssues
(since it decapitalizes)I think this is better situation on reflection (pun intented)
Originally I wanted to avoid confusion
where if some one previously had declared a record like method (
behavior()
) and didn't want it to be used. BUT this is crazy to have such confusion and I don't think anyone would do it on purpose AND graphql-java 20 can introduce new behaviors if on balance its worth it. And I think it's worth it.So this is the new support.
This will also help Kotlin with its special
isXXX
naming (or lack there of)given
we get this generated
So this new code will find directly named methods first and then use the
get/is
style naming secondaryThis will work for Kotlin and Java records a like