-
Notifications
You must be signed in to change notification settings - Fork 15
Incorrect validations for eg. CreateIndex, JobModifyIndex, ModifyIndex #87
Comments
Hi @schlumpfit Thanks so much for taking a look at the project! The code for each target client actually gets generated by the OpenAPI Generator. It's not super obvious how the flow works, so I'll try to explain here and look at ways to make the docs better in general. The To change the output of the generated code, you would have to affect the change using whatever tool you are using to generate the clients. In our case, the OpenAPI Generator allows us to configure custom templates in the All that said, these examples look a little off to me. The Go one does what I expect. The In the cases of Ruby and Python that you point out, that generated code looks wrong. I'm not overly familiar with either language, but a quick internet search leads me to believe that neither has the concept of an explicit Either way, if I understand the example you posted, the issue lies somewhere in the upstream OpenAPI Generator templates for Ruby and Python. An We maintain a Go implementation in the Again, thanks for trying out the project, and let me know if I can help in any way. Also, if you are interested in helping improve the quality of the Ruby or Python clients, let me know. We have monthly community meetings where we can interact synchronously, and as always, PRs are welcome. |
Hi @DerekStrickland, TLDR: It is not an issue of the generator per se but of the openapi document describing the model I am familiar with OpenAPI and Swagger and already used it in some of my projects (ruby/python/rust). According to my understanding the issue here comes from the generator that generates the OAS and not the client generators directly (although they should catch this glitch). This quick example seems to proof my understanding: openapi: 3.0.3
info:
description: Example
version: "0.1.0"
title: OpenApiDataTypes
paths:
/some_model:
get:
description: Get some model
responses:
'200':
description: success
content:
application/json:
schema:
$ref: "#/components/schemas/SomeModel"
components:
schemas:
SomeModel:
type: object
properties:
value_integer:
type: integer
value_with_format_int32:
type: integer
format: int32
value_with_format_int64:
type: integer
format: int64
value_with_validation_and_format_int32:
type: integer
format: int32
minimum: "-2147483648"
maximum: 2147483647
value_with_validation_and_format_int64:
type: integer
format: int64
minimum: "-9223372036854775808"
maximum: 9223372036854775807
value_with_validation_and_format_uint64_overflow:
type: integer
minimum: 0
maximum: 1.8446744073709552e+19
# value_with_validation_and_format_uint64_overflow:
# type: integer
# format: int64
# minimum: 0
# maximum: 1.8446744073709552e+19 Given this spec above only properties with min/max values get a validation. It seems to me the go-generator just ignores them. So I think it is more by luck that the go client works. The produced ruby validations look as follow: ...
# Check to see if the all the properties in the model are valid
# @return true if the model is valid
def valid?
return false if !@value_with_validation_and_format_int32.nil? && @value_with_validation_and_format_int32 > 2147483647
return false if !@value_with_validation_and_format_int32.nil? && @value_with_validation_and_format_int32 < -2147483648
return false if !@value_with_validation_and_format_int64.nil? && @value_with_validation_and_format_int64 > 9223372036854775807
return false if !@value_with_validation_and_format_int64.nil? && @value_with_validation_and_format_int64 < -9223372036854775808
return false if !@value_with_validation_and_format_uint64_overflow.nil? && @value_with_validation_and_format_uint64_overflow > 384
return false if !@value_with_validation_and_format_uint64_overflow.nil? && @value_with_validation_and_format_uint64_overflow < 0
true
end
... The commented out part actually raises an generator error (without useful information)
Could you please provide me the reason why you closed the ticket? The code/behaviour I am referring to was generated using the openapi-generator with the document under |
Hi again @schlumpfit, Oh, how embarrassing! Thank you for being so kind and detailed in your response. Your observation looks absolutely correct. I closed the issue thinking that the problem was in the upstream generator, but am definitely re-opening this now. Please forgive my mistake. In my haste to get you a timely response, I didn't dig deep enough and relied on what I thought I saw. 😢 Based on what you've shared with me here, I'll have to go take a look at the code in The I'll have to dig into whether there is a bug in I totally missed this, so thank you again for pointing it out, and thank you for correcting my misfire on the original response with patience, kindness, and examples! Cheers, |
@DerekStrickland Hi I am running into this issue and am interested in fixing it. Can you give me a bit more pointer on where to start looking at this issue? This is my first time dealing with code generator code, so I am a bit lost on where to start looking. If I understand correctly, "EvalCreateIndex" is an EvalCreateIndex:
maximum: 1.8446744073709552e+19
minimum: 0
type: integer Note, the range is EvalCreateIndex:
format: int32 # or int64?
type: integer Is this correct understanding? |
Update, actually the generator is behaving correctly because the actual schema it reads from is: // JobRegisterResponse is used to respond to a job registration
type JobRegisterResponse struct {
EvalID string
EvalCreateIndex uint64
JobModifyIndex uint64
// Warnings contains any warnings about the given job. These may include
// deprecation warnings.
Warnings string
QueryMeta
} Note, the maximum: 1.8446744073709552e+19
minimum: 0
type: integer The min and max are correct, but what is the openapi expectation of uin64? |
Update, there is the issue. OpenAPITools/openapi-generator#11940 In all honesty, python openapi generator should fix this. The The alternative is to only generate the minimum for If you are OK with the approach to removing maximum when the type is |
Hi @yihuaf Thanks for looking into this! I'm sorry it took so long to respond. I was on vacation last week. I'm seeing a lot of discussion around this topic, and the approach How does that sound? |
As an example the JobListStub is defined in the
openapi.yml
as:Which seems to generate the
golang
code without further validations:But for ruby/python validations are added:
The text was updated successfully, but these errors were encountered: