json рекурсия схемы, кажется, не правильно проверяет - PullRequest
Новая
       18

json рекурсия схемы, кажется, не правильно проверяет

0 голосов
/ 19 апреля 2020

Я просматриваю документы, чтобы попытаться выяснить, как работают циклы, чтобы я мог проверить каждый объект массива объектов, соответствующих схеме.

Кажется, что рекурсия - это то, что я хочу, но приведенный пример не работа: https://json-schema.org/understanding-json-schema/structuring.html

Я пытаюсь проверить этот пример, но он всегда "действителен". Я попытался изменить все имена полей в json, и это не имеет значения: enter image description here

Не уверен, что происходит. В этом примере, как мне проверить, чтобы каждый дочерний элемент соответствовал схеме человека (без статической записи каждого в схеме).

Например, я хочу проверить это json. может быть любое количество объектов в toplevel и любое количество объектов в "objectsList". Я хочу убедиться, что каждый объект в "objectsList" имеет правильные имена и типы полей (опять же без жесткого кодирования всей вещи в схеме): 

{
  "toplevel": {
    "objectOne": {
      "objectsList": [
        {
          "field1": 1231,
          "field2": "sekfjlskjflsdf",
          "field3": ["ssss","eeee"],
        },
        {
          "field1": 11,
          "field2": "sef",
          "field3": ["eeee","qqqq"],
        },
        {
          "field1": 1231,
          "field2": "wwwww",
          "field3": ["sisjflkssss","esdfsdeee"],
        },
      ]
    },
    "objectTwo": {
      "objectsList": [
        {
          "field1": 99999,
          "field2": "yuyuyuyuyu",
          "field3": ["ssssuuu","eeeeeee"],
        },
        {
          "field1": 221,
          "field2": "vesdlkfjssef",
          "field3": ["ewerweeee","ddddq"],
        },
      ]
    },
  }
}

Ответы [ 2 ]

2 голосов
/ 19 апреля 2020

Что не так?

Проблема здесь не в рекурсии - ваша схема выглядит хорошо.

Основная проблема такая же, как здесь: { ссылка }

JSON Схема предназначена для расширяемости. Это означает, что он позволяет добавлять любые дополнительные свойства, если они не конфликтуют с известными / ожидаемыми ключевыми словами.

Решение

Решением здесь является добавление "additionalProperties": false в вашей "персоне" (из скриншота) и схеме верхнего уровня, чтобы эти некорректные объекты не были приняты То же самое относится и ко второму примеру: в любых определениях "type": "object" вам нужно будет добавить "additionalProperties": false, если вы не хотите разрешать определение этих посторонних свойств.

В качестве альтернативы вы можете объявить ожидаемые свойства как required, чтобы гарантировать, что хотя бы те присутствуют.

Почему?

Согласно json -schema.org / понимание- json -schema (выделение мое):

Ключевое слово additionalProperties используется для управления обработкой лишних вещей, то есть properties, чьи имена не указаны в ключевом слове properties. По умолчанию разрешены любые дополнительные свойства.

Ключевое слово additionalProperties может быть либо логическим, либо объектом. Если additionalProperties является логическим значением и имеет значение false, дополнительные свойства не будут разрешены.

0 голосов
/ 19 апреля 2020

Чтобы указать скриншот, который вы опубликовали, и причины, по которым экземпляр проходит:

  1. Схема ищет свойство person, но это свойство не существует.
  2. Схема не объявляет, что требуется person.
  3. Схема не объявляет требования к неопределенным свойствам, поэтому она всегда будет принимать свойство personsdfsd с любым значением в нем, без дальнейшей проверки.

Короче говоря, ваши JSON данные неверны, и ваша схема не имеет никакой защиты от этого.

Кроме этого, ваша схема выглядит хорошо. Следует проверить, что элементы в свойстве children соответствуют подсхеме определения person.

...