Skip to content
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

feat: error for oneOf, anyOf, allOf schema that does not use array #143

Merged
merged 5 commits into from
Feb 24, 2020

Conversation

barrett-schonefeld
Copy link
Contributor

@barrett-schonefeld barrett-schonefeld commented Feb 19, 2020

Changes:

  • added default error for oneOf, anyOf, or allOf schema that is not use top-level array

Tests:

  • added tests when oneOf, anyOf, or allOf schemas are nested ("oneOf allOf," for example), when oneOf, anyOf, or allOf schema is used as a property in an obect, and when oneOf, anyOf, or allOf schema used as items in array
  • updated schema-ibm test to import the default config values and made necessary changes to test to account for unexpected errors and warnings resulting from having all default values present
  • added test to ensure errors not issued when compose models use an array

@codecov
Copy link

codecov bot commented Feb 19, 2020

Codecov Report

Merging #143 into master will increase coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #143      +/-   ##
=========================================
+ Coverage   92.88%   92.9%   +0.02%     
=========================================
  Files          61      61              
  Lines        2109    2115       +6     
=========================================
+ Hits         1959    1965       +6     
  Misses        150     150
Impacted Files Coverage Δ
...validation/2and3/semantic-validators/schema-ibm.js 99.25% <100%> (+0.03%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9f18deb...ec7c365. Read the comment docs.

Copy link
Member

@dpopp07 dpopp07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just a couple minor changes

test/cli-validator/mockFiles/oas3/composeModelProps.yaml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
test/plugins/validation/2and3/schema-ibm.js Show resolved Hide resolved
Copy link
Contributor

@mkistler mkistler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I recommend removing the configuration of this check altogether -- then we can avoid the need to come up with a concise but descriptive name for what is essentially an OpenAPI requirement.

README.md Outdated Show resolved Hide resolved
README.md Outdated
@@ -251,6 +251,7 @@ The supported rules are described below:
| no_property_description | Flag any schema that contains a 'property' without a `description` field. | shared |
| description_mentions_json | Flag any schema with a 'property' description that mentions the word 'JSON'. | shared |
| array_of_arrays | Flag any schema with a 'property' of type `array` with items of type `array`. | shared |
| compose_model_field_not_array | Flag any compose model schema that does not use an array. | shared |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep this configurable, I think we want a clearer name and description. "compose model" is a term from the SDK generator -- not used in OpenAPI or JSON Schema. So better to use something like "allOf_value_not_array" and "Flag any allOf schema attribute whose value is not an array".

Copy link
Contributor Author

@barrett-schonefeld barrett-schonefeld Feb 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose to use compose model because this PR checks that allOf, anyOf, and oneOf use arrays. In the following changes, I am going to remove the configuration option, but I want to make sure you agree with the choice to include anyOf and oneOf.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes -- we should check all three. I made my suggestion before I saw the code below.

invalid_type_format_pair: 'error'
}
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the changes above here appear to be unrelated to this feature.

Copy link
Contributor Author

@barrett-schonefeld barrett-schonefeld Feb 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, while I was introducing tests to this module, I thought it would be a good idea to clean up the individual declarations of config and replace them with one import. I changed the config name to customConfig for the cases where the test uses a custom value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ I support these changes

@barrett-schonefeld barrett-schonefeld changed the title feat: default error for compose models schema that does not use array feat: error for oneOf, anyOf, allOf schema that does not use array Feb 21, 2020
Barrett Schonefeld added 5 commits February 21, 2020 12:43
…r parameter

- added a findOctetSequences function to handle the logic of finding schema type: string, format: binary for cases of nested arrays, objects, nested arrays of type object, objects with properties that are nested arrays, and objects with properties that are objects, and the simple case where a schema uses type: string, format: binary directly. This function takes a schema object from a resolvedSpec and returns a list of paths to octet sequences (empty list if none found).
- added logic to handle application/json request bodies that use schema type: string, format: binary
- added logic to handle application/json response bodies of type: string, format: binary
- added logic to handle parameters of type: string, format: binary
- removed 'binary' as a valid format for type: string parameters. parameters of type: string, format: binary will result in "type+format not well-defined" error
- added tests to ensure warnings are issued for request bodies, response bodies, and parameters with schema, type: string, format: binary
- added complex tests to exercise combinations of nested arrays and objects that contain schema type: string, format: binary (complex tests done on response bodies)
- added "json_or_param_binary_string" as to .defaultsForValidator as a warning in the shared.schemas section
- added "json_or_param_binary_string" configuration option to the README.md rules and defaults sections in the schemas section
…r parameter

- added a findOctetSequences function to handle the logic of finding schema type: string, format: binary for cases of nested arrays, objects, nested arrays of type object, objects with properties that are nested arrays, and objects with properties that are objects, and the simple case where a schema uses type: string, format: binary directly. This function takes a schema object from a resolvedSpec and returns a list of paths to octet sequences (empty list if none found).
- added logic to handle application/json request bodies that use schema type: string, format: binary
- added logic to handle application/json response bodies of type: string, format: binary
- added logic to handle parameters of type: string, format: binary
- removed 'binary' as a valid format for type: string parameters. parameters of type: string, format: binary will result in "type+format not well-defined" error
- added tests to ensure warnings are issued for request bodies, response bodies, and parameters with schema, type: string, format: binary
- added complex tests to exercise combinations of nested arrays and objects that contain schema type: string, format: binary (complex tests done on response bodies)
- added "binary_string" as to .defaultsForValidator as a warning in the shared.schemas section
- added "binary_string" configuration option to the README.md rules and defaults sections in the schemas section
…r parameter

- added a hasOctetSequence module to handle the logic of finding schema type: string, format: binary for cases of nested arrays, objects, nested arrays of type object, objects with properties that are nested arrays, and objects with properties that are objects, and the simple case where a schema uses type: string, format: binary directly. This function takes a schema object from a resolvedSpec and returns a list of paths to octet sequences (empty list if none found).
- added logic to handle application/json request bodies that use schema type: string, format: binary
- added logic to handle application/json response bodies of type: string, format: binary
- added logic to handle parameters of type: string, format: binary
- removed 'binary' as a valid format for type: string parameters. parameters of type: string, format: binary will result in "type+format not well-defined" error
- added tests to ensure warnings are issued for request bodies, response bodies, and parameters with schema, type: string, format: binary
- added complex tests to exercise combinations of nested arrays and objects that contain schema type: string, format: binary (complex tests done on response bodies)
- added "binary_string" as to .defaultsForValidator as a warning in the shared.schemas section
- added "binary_string" configuration option to the README.md rules and defaults sections in the schemas section
…rrors

- introduced MessageCarrier class to centralize the logic/checks for adding warnings and errors.
- introduced an instance of this class in each semantic validator to provide uniform warning and error reporting
- added unit tests for the MessageCarrier class
- added error for oneOf, anyOf, or allOf schema that is not use top-level array
- updated schema-ibm test to import the default config values and made necessary changes to test to account for unexpected errors and warnings resulting from having all default values present
- added tests when oneOf, anyOf, or allOf schemas are nested ("oneOf allOf," for example), when oneOf, anyOf, or allOf schema is used as a property in an obect, and when oneOf, anyOf, or allOf schema used as items in array
- added test to ensure errors not issued when compose models use an array
Copy link
Member

@dpopp07 dpopp07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! I'll give @mkistler one more change to review before merging

Copy link
Contributor

@mkistler mkistler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

@dpopp07 dpopp07 merged commit 1db6b27 into master Feb 24, 2020
@dpopp07 dpopp07 deleted the allOf-array branch February 24, 2020 15:58
dpopp07 pushed a commit that referenced this pull request Feb 24, 2020
# [0.23.0](v0.22.0...v0.23.0) (2020-02-24)

### Features

* error for oneOf, anyOf, allOf schema that does not use array ([#143](#143)) ([1db6b27](1db6b27))
@dpopp07
Copy link
Member

dpopp07 commented Feb 24, 2020

🎉 This PR is included in version 0.23.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants