model-util: Add support for generating example data for Primitive Schema

[nbhusare]

Expected Behaviour

You should get the example data if you input a Primitive Schema to the Model Utility.
For example - {"type":"integer"}. The expected result here is an integer value.

Actual Behaviour

The utility fails with an NPE.

The method loadModelString in ModelObject does not take into consideration Primitive types schema's. It makes a hard assumption about the existence of the following fields - items, properties, required...

Sample Code that illustrates the problem

val schema = {"type":"integer"};
new ModelObject(schema, false);

Platform and Version

1.0.4

Logs taken while reproducing the problem

java.lang.NullPointerException
	at com.adobe.ride.utilities.model.ModelObject.loadModelString(ModelObject.java:101)
	at com.adobe.ride.utilities.model.ModelObject.<init>(ModelObject.java:285)

[tedcasey]

Hi Neeraj,

Thank you for filing the issue. Yes, it's true that Ride expects those fields. They are standard in json schema as defined below:
http://json-schema.org/learn/miscellaneous-examples.html
https://www.jsonschemavalidator.net/

Do you have some documentation showing that the schema you have above is indeed valid?

Thank you!

Ted

[tedepstein]

Hi @tedcasey ,

JSON Schemas can specify any type, or combination of types, as described here. Allowed type values include "null", "boolean", "object", "array", "number", "integer", or "string".

The JSON Schema spec itself is very light on examples, and the examples document you pointed to only covers a tiny part of the range that JSON Schema can express. But you'll see a few examples of string-typed and array-typed schemas starting in section 8.5.

You'll also see that JSON Schema Validator and JSON Schema Lint both correctly validate primitive-typed and array-typed schemas, in addition to object-typed schemas.

In our domain of API specifications, it is possible, though not very common, to specify a request or response message body as a primitive type. It is much more common for requests and responses to be objects, object arrays, or (somewhat less commonly) primitive arrays.

But OpenAPI also uses schemas to specify parameter values, which are usually primitive-typed; sometimes primitive arrays.

Examples:

A path parameter of a string value:

{
  "name": "username",
  "in": "path",
  "description": "username to fetch",
  "required": true,
  "schema": {
    "type": "string"
  }
}

A header parameter with an array of 64 bit integer numbers:

{
  "name": "token",
  "in": "header",
  "description": "token to be passed as a header",
  "required": true,
  "schema": {
    "type": "array",
    "items": {
      "type": "integer",
      "format": "int64"
    }
  },
  "style": "simple"
}

Paging parameters:

{
  ...
  "parameters": {
    "skipParam": {
      "name": "skip",
      "in": "query",
      "description": "number of items to skip",
      "required": true,
      "schema": {
        "type": "integer",
        "format": "int32"
      }
    },
    "limitParam": {
      "name": "limit",
      "in": "query",
      "description": "max records to return",
      "required": true,
      "schema" : {
        "type": "integer",
        "format": "int32"
      }
    }
  },
  ...

(Note: The OpenAPI 3.0 specification devotes a fair amount of space to describing object-typed parameters, and the various ways objects can be mapped into query strings. But this part of the spec is IMO a bit of a mess, and it may create the false impression that this is a common usage pattern. It really isn't. Most OpenAPI documents will specify parameters as primitives.)

[tedcasey]

Hmm, it's interesting that I hadn't come across this before. This is another example of why I wish the JSON schema spec was perhaps a bit more structured, as you allude to above.

That said, this feature request requires some thought around implementation. I'll log it as a feature request, but in the meantime, PRs are always welcome :). My first thought on implementation would be that when Ride looks for a properties field, if it doesn't find one, attempt to use the entire json statement in a similar way.

I'll update here as I have more info.

[tedepstein]

@tedcasey , if the type keyword is present, that's the clearest indicator of what kind of value is expected. It will almost always be a single string value indicating the one allowed type.

JSON Schema does allow you to define discrete unions like "type" : ["string", "object"]. I think this is one of several corner cases where it's OK for the example generator to just flip a coin, or return null, or (last resort) throw an exception. You can always add support for those oddball cases later.

If type is not specified, as you said, properties is a good clue that an object schema is intended. Other possibilities include additionalProperties, patternProperties, or propertyNames. It's rare that a schema would have one of those three and not have a statically defined properties map. But again, JSON Schema allows it.

[tedcasey]

@tedepstein , Actually, looking back over the code, Ride expects a type at the root of the schema def. The reason for this is that there are different logical paths in Ride for schemas of type array (Ride looks for an "items" node) and schemas of type object (Ride looks for a properties node).

To handle the cases you're talking about, we should use a switch on loadModelString to account for other types instead of a simple conditional here: https://github.com/adobe/ride/blob/develop/utilities/ride-model-util/src/main/java/com/adobe/ride/utilities/model/ModelObject.java#L96

[tedcasey]

Incidentally, in the not too distant future, I would like to split up the ModelObject into more classes or perhaps sub-classes, or both. Over 1600 lines of code in one class is a bit much for me, and breaking it up along these lines is one potential area for improvement.

[tedcasey]

Issue fixed with the 1.0.5 release of Ride. Thanks, Neeraj!