-
Notifications
You must be signed in to change notification settings - Fork 135
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
JsonIgnore issue #130
Comments
Is there a concept of write-only in schema? Can you give an example of expected schema, along with what is currently produced? |
@cowtowncoder wow, thanks for such a fast response! Unless I'm mis-reading it, Section 10.3 of the spec defines the concept readOnly and writeOnly however for my purposes I'd be happy to simply have the field present in the schema as a normal schema property. This should be enough for clients to generate payloads containing the field as required by the server. An example would look something like: {
"type" : "object",
"id" : "User",
"properties" : {
"password" : {
"type" : "string"
}
} So just a normal StringSchema with no special decoration. From what I can see of a cursory read of the source the field itself isn't exposed as opposed to not being used, given this I could add a 'post-processor' that would add the field back in based on the annotations. I'm already doing something similar for java.time.Instant fields but I was hoping there would be some simple way of doing this. EDIT: Actually, that was a draft of the next release I was reading. So it seems the concept is coming but not yet here 😄. Full draft can be found here with release notes here |
I have an issue where I am trying to produce a schema for an object that has a password field. Obviously the field should be write-only and never be be serialised so it is marked as such in the entity but when I try to create the schema the field is omitted completely.
I have tried all of the following but they all result in the same outcome, no password field in the schema.
I think that from a schema perspective the field should be defined as it is write-only and and clients of the service will need to send the field under different circumstances. I'm guessing this has something to do with the underlying use of jackson databind module but can you give any advice on how to achieve the desired outcome?
Thanks, Andy.
The text was updated successfully, but these errors were encountered: