Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

OpenAPI: exclusiveMinimum/Maximum #412

Closed
wroge opened this issue May 31, 2020 · 6 comments
Closed

OpenAPI: exclusiveMinimum/Maximum #412

wroge opened this issue May 31, 2020 · 6 comments
Labels
FeedbackWanted Further information is requested

Comments

@wroge
Copy link
Contributor

wroge commented May 31, 2020

What version of CUE are you using (cue version)?

$ cue version
cue version v0.2.0 darwin/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

#A: {
    value: >0 | *1
}
cue def -o openapi+yaml:openapi2.yaml test.cue

What did you expect to see?

openapi: 3.0.0
info:
  title: Generated by cue.
  version: no version
paths: {}
components:
  schemas:
    A:
      type: object
      required:
        - value
      properties:
        value:
          type: number
          minimum: 0
          exclusiveMinimum: true
          default: 1

What did you see instead?

openapi: 3.0.0
info:
  title: Generated by cue.
  version: no version
paths: {}
components:
  schemas:
    A:
      type: object
      required:
        - value
      properties:
        value:
          type: number
          exclusiveMinimum: 0
          default: 1

I copied this code into the Swagger Editor and received this error:

Structural error at components.schemas.A.properties.value.exclusiveMinimum
should be boolean
@mpvl
Copy link
Contributor

mpvl commented May 31, 2020

I guess it depends on the version of JSON Schema you consider. CUE interprets it to the current standard.

Is there any particular JSON Schema version that is required for OpenAPI?

@wroge
Copy link
Contributor Author

wroge commented Jun 1, 2020

I didn't know there was a divergence between the JSON schema and OpenAPI. OAPI Issue 1977

The list of differences is now tiny, only 4 extra keywords, with 2 notes about how exlusiveMinimum and exclusiveMaximum can be used in two ways (in order to maintain BC with OpenAPI v3.0).

@mpvl mpvl added wontfix This will not be worked on WorkingAsIntended FeedbackWanted Further information is requested and removed NeedsInvestigation wontfix This will not be worked on WorkingAsIntended labels Jun 2, 2020
@mpvl
Copy link
Contributor

mpvl commented Jun 2, 2020

Yeah, not the easiest thing to manage, with both CUE, OpenAPI and JSON Schema being moving targets. We're working at least to get CUE to a backwards compatibility guarantee, modulo backwards incompatible changes imposed by OpenAPI/JSON Schema.

Note there is also somewhat of a divergence between OpenAPI for CRDs versus more general OpenAPI standards.

I guess the issue is that this is not working for v3.0.0, which accepts only booleans. It seems reasonable to support this, weren't it for the fact hat OpenAPI and JSON Schema themselves are fairly fast-moving targets.

How much could people live with only supporting v3.1.0?

@wroge
Copy link
Contributor Author

wroge commented Jun 5, 2020

I think CUE can be very useful if it knows all the inconsistencies of the other formats. However, it makes sense to wait for version 3.1.0 if all problems are automatically fixed.

@mpvl
Copy link
Contributor

mpvl commented Jun 16, 2020

I've changed the behavior to generate bool for OpenAPI. I've added a version option in the config and changed it such that it will start printing numbers again for v3.1.0.

See https://cue-review.googlesource.com/c/cue/+/6361

This also adds reading support in jsonschema for this legacy encoding.

@cueckoo
Copy link

cueckoo commented Jul 3, 2021

This issue has been migrated to cue-lang/cue#412.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeedbackWanted Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants