-
Notifications
You must be signed in to change notification settings - Fork 114
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
if there is no Validator associated with a schema Field it generates illegal json #50
Comments
Why is it invalid? |
Extra comma. I think we can fix that part but I'm wondering if we shouldn't
flag it as an error? Is a schema field without a validator?
…On Mon, Nov 28, 2016, 21:54 Olivier Poitrey ***@***.***> wrote:
Why is it invalid?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#50 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACK5U--KxuKC6X0zdxH71ADOo7SQMMMeks5rC74ggaJpZM4K-gm9>
.
|
Wouldn't it be useful to let a field be of any type/format? |
Not sure that's legal in json schema and also defeats the point of schema
as a validator. I'm not sure what the use case you have in mind is.
…On Mon, Nov 28, 2016, 22:53 Olivier Poitrey ***@***.***> wrote:
Wouldn't it be useful to let a field be of any type/format?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#50 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACK5U6uGB38vDqJkp3l38H86jWIpFokxks5rC8v0gaJpZM4K-gm9>
.
|
No particular use-case. We should certainly throw an error, you're right. |
It's perfectly legal to have a field of an arbitrary type in JSON Schema - even an empty dictionary is a valid JSON Schema! |
I would recommemd dealing with the comma situation, as the way we add commas feels quite hard-coded and as this issue proves, perhaps a bit error prone. Would it be possible to have anorther look at what the JSON package is doing? Or perhaps even utilize the JSON package for tag serialization? One usecase I see for not specifying a validation for one particular field in a Schema, would be a logging API, or perhaps a job queue with arbitrary input parameters. |
Thinking out loud, perhaps one way could be to make it the responsibility of the "writer" (e.g. call it objectEncoder, arrayEncoder) to know when an object start, printe the leading/trailing { or [ and the commas between key/value pairs. |
I think fixing the bug first would be good, then if you feel strongly enough to rewrite the serializer then open a separate issue. While it may be legal to generate a typeless schema I'm not really sure what that purpose it would serve other than to add to confusion. |
My initial point is that using schema without a validator appears to be an incorrect usage of the API and should probably be considered an error by something like the JSONSchema. If you want the validator to be a wildcard wouldn't something like AnyOf be a better choice? @rs do you consider a missing validator as an incorrect API usage or a valid use case? |
Yes in the current state of the code, we should not allow validator-less fields. It is easier to reopen that later if we feel like implementing this use-case. |
Thanks I'll try and work up a pull request
…On Tue, Nov 29, 2016, 09:54 Olivier Poitrey ***@***.***> wrote:
Yes in the current state of the code, we should not allow validator-less
fields. It is easier to reopen that later if we feel like implementing this
use-case.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#50 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACK5U5lwVQEkHajvLnq0TdpuPlChmra9ks5rDGbBgaJpZM4K-gm9>
.
|
If you are going to raise an error with a nill validatior, please consider to at least make it a NotYetImplemented type error... In my opinion, the use case seams completely valid. Even more so if nill validatiors are already allowed by the rest of the rest-layer code. @rs, is this the case? To go more in depth with the use-case, consider a job queue API with: Objekt task:
Solving it with AnyOf would then require quite ugly code... Cheers |
I'm not sure the current code expect a field with not validator. |
Feel free to implement a don't care validator. I think that solves your use
case. This is an incorrect usage of the API, not a semantic issue. This
could be solved by implementing a new validator that explicitly outlines
the meaning rather than relying on a implicit behavior. I was actually
thinking about implementing this in the compile phase.
…On Wed, Nov 30, 2016, 20:56 Olivier Poitrey ***@***.***> wrote:
I'm not sure the current code expect a field with not validator.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#50 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACK5U_PLiL7graF-UiIp_4qPQrOOuaMxks5rDlN_gaJpZM4K-gm9>
.
|
Idomatic Go programs actually has a good history for making the nil value useful. Anyway, let's discuss this in a separate issue as you suggest. |
When a validator hasn't been set the JSONSchema emits invalid JSON. - add a test case replicating the issue - extend errWriter to track properties written - add a Comma helper which emits commas when at least 1 property has been written - extract function from encoding loop serializeField - change validator check to test validator for nil instead of just errors - errWriter takes care of errors
- if both the Validator and the Schema have not been set, consider this an error and report it during validation.
When a validator hasn't been set the JSONSchema emits invalid JSON. - add a test case replicating the issue - extend errWriter to track properties written - add a Comma helper which emits commas when at least 1 property has been written - extract function from encoding loop serializeField - change validator check to test validator for nil instead of just errors - errWriter takes care of errors
When a validator hasn't been set the JSONSchema emits invalid JSON. - add a test case replicating the issue - extend errWriter to track properties written - add a Comma helper which emits commas when at least 1 property has been written - extract function from encoding loop serializeField - change validator check to test validator for nil instead of just errors - errWriter takes care of errors
When a validator hasn't been set the JSONSchema emits invalid JSON. - Add a test case replicating the issue - Create `fieldWriter` type which embeds `errWriter` as field tracking behavior is orthogaonal to `errWriters` purpose - Extract function from encoding loop `serializeField` - Change validator check to test validator for nil instead of just errors - ErrWriter takes care of errors
@yanfali, is this now fixed? |
Should be, there's a test that confirms the issue in the PR. |
Let's close it then:-) |
e.g. "authentication": schema.Field{
Description: "Ignored authentication token",
Required: false,
},
Is perfectly valid go code, and the validator runs without complaint, but for the JSON schema it generates illegal JSON Schema. Should we make this a run time error if we discover it in the JSONSchema or in schema?
The text was updated successfully, but these errors were encountered: