De-duplicate equal object entries in schema "anyOf" field for fixed-type array

[Ge11ert]

Let's assume, I have the next apib:

# Group Example
## GET /

+ Response 200 (application/json)
   + Attributes (array, fixed-type)
       + (object)
           + msg: 'hello' (string)
           + id: 2 (number)
       + (object)
           + msg: 'bye' (string)
           + id: 3 (number)

And for this input I get such JSON Schema:

$ ./build/Release/drafter.exe -f json simple.apib | ./tools/refract-filter.py
{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "object",
        "properties": {
          "msg": {
            "type": "string"
          },
          "id": {
            "type": "number"
          }
        }
      }
    ]
  }
}

This is fine. I have equal structures as array's nested members and field "anyOf" contains only one member.

The next step: I swap the places of the second object fields:

# Group Example
## GET /

+ Response 200 (application/json)
   + Attributes (array, fixed-type)
       + (object)
           + msg: 'hello' (string)
           + id: 2 (number)
       + (object)
           + id: 3 (number)
           + msg: 'bye' (string)

AFAIK, in objects, there's no difference in fields order, these two objects should be equal. But emplace_unique (or whatever doing the job) cannot handle this case:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "object",
        "properties": {
          "msg": {
            "type": "string"
          },
          "id": {
            "type": "number"
          }
        }
      },
      {
        "type": "object",
        "properties": {
          "id": {
            "type": "number"
          },
          "msg": {
            "type": "string"
          }
        }
      }
    ]
  }
}

What I expected to see: the same output as the first JSON Schema.

FYI, I have the latest version (4.0.0-pre2)

I think this has some relation to #566

[kylef]

@Ge11ert We've added some optimisations to prevent this which are now in master if you'd like to give it a go. We'll get this into our next release of Drafter (Protagonist, etc).

[Ge11ert]

Great, thanks!