Feature request: ignore specific property

[SteveNewhouse]

Would be great if you could ignore at the property level. I have objects where it wouldn't make sense for all of the properties to be set at the same time, and for mocking purposes, it'd be great to be able to ignore some of the properties.

Something like

...
definitions:
  Pet:
    allOf:
      - $ref: '#/definitions/NewPet'
      - required:
        - id
        properties:
          id:
            type: integer
            format: int64
            x-chance-type: none # or ignore / exclude, etc...

[dzdrazil]

I'm a bit mixed on this one. It feels like always ignoring a property violates both the schema definition as a resource, as well as the dynamic nature of the data.

Option a) if some properties are mutually exclusive, are they actually the same resource? Perhaps there should be a 'multi-$ref' feature that returns a random schema from a set list

Option b) If it makes sense for mutually exclusive properties to be defined on the same schema, perhaps properties could be 'tagged'- so when generating an object, pick a random tag out of all the tags on its properties, and only generate values for properties with a matching tag.

Option c) argue that neither of these should be the responsibility of this library, and let people load in their own generators for these problems.

I'll give it some thought and maybe do one or all of the above.

[SteveNewhouse]

Here's an example from my company's domain:

  Pricing:
    type: object
    properties:
      flatPrice:
        type: number
        minimum: 0
      perHour:
        type: number
        minimum: 0
      maxHours:
        type: integer
        minimum: 0
      perAdditionalHour:
        type: number
        minimum: 0
      maxAdditionalHours:
        type: integer
        minimum: 0
      perUnit:
        type: number
        minimum: 0
      maxUnits:
        type: integer
        minimum: 0
    example:
      perHour: 25.00
      maxhours: 5
      perAdditionalHour: 15.00
      maxAdditionalHours: 2

This schema describes the pricing for a job.. sometimes pricing is "per unit", i.e. "you get $5 per window you clean." Sometimes it is "per hour", i.e. "$25 per hour, for up to 3 hours"... there's also flat rate and dual-rate-hourly pricing. When we use flat pricing, for example, we wouldn't include fields for the other pricing type.

We didn't break out separate schemas for each, though we could have. Your arguments are valid, however...

[dzdrazil]

That makes sense. In an ideal world, I'd probably recommend defining your schema such that you have multiple billing schemas, which are composed together using the JSON Schema's "oneOf" type. However, Swagger explicitly did not support 'oneOf'. See OAI/OpenAPI-Specification#57

However, we are not in an ideal world- you may have an existing API that isn't perfectly RESTful, or maybe can't change to accommodate, Swagger doesn't completely implement JSON Schema, and those things are all okay.

Given the new (to me) information that Swagger's type composition isn't as good as I thought it was, I'm more inclined now to build in some support for this issue. At this point, I'm inclined to go with the tagging approach.