-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Binary property support #171
Binary property support #171
Conversation
@@ -105,6 +105,9 @@ public JType apply(String nodeName, JsonNode node, JClassContainer jClassContain | |||
if (node.has("format")) { | |||
type = ruleFactory.getFormatRule().apply(nodeName, node.get("format"), type, schema); | |||
} | |||
else if(propertyTypeName.equals("string") && node.has("media")) { | |||
type = ruleFactory.getMediaRule().apply(nodeName, node.get("media"), type, schema); | |||
} |
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.
@joelittlejohn does this seem like the correct way for format
and media
to interact, when they are both present?
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.
Yes, I think so. It'll minimize backwards-compatibility problems in the obscure case that someone is using both format and media. I think you could make an argument for either to win out in this case but I think you've taken the right path.
I think this change is almost complete. There should probably be some kind of testing for the interplay between this feature and things like |
<artifactId>commons-codec</artifactId> | ||
<version>1.9</version> | ||
<scope>test</scope> | ||
</dependency> |
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.
Be aware, I added a dependency to commons-codec
, in the test scope.
@joelittlejohn I think this change is done. There are a lot of commits, so a squash is probably in order. If you think this PR looks good, I will squash these just before you pull, so your history is clean. This is what I changed recently:
|
This looks brilliant Christian. Sorry for the delay, I've been out of town for the last few days. I must say your attention to detail and sympathy with the existing conventions, structure and layout of this project are exceptional. A couple of tiny format issues:
I've given this a review ( If you have any feedback on the overall structure and ease of changing this code then please don't hesitate to comment. Cheers! |
- add a new rule for media - added media rule to the rule factory - added code to type rule to trigger the media rule - added test cases for binary fields.
@joelittlejohn Thanks! I think this change is good to go. I squashed and rebased the commit, so this should be ready to merge. Overall, it has not been hard to navigate the project and find things I am looking for. There were two things that did cause me problems:
Otherwise, this project has been a pleasure to work with. Thanks so much for your feedback during the addition of this feature. There is nothing worse than preparing a patch, only to rework it again during the PR. -Christian |
Coincidentally I was actually looking into those JDK 8 failures last night. The current master should compile on JDK 8.
|
This feature will provide support for binary properties, using the
media
block, as specified by the JSON Hyper Schema specification. Currently, this PR only includes the test case for the functionality.Blocks declared in the form:
will create properties of this form in the POJOs:
Media blocks without a
binaryEncoding
will be ignored.