Dlaczego mój wygenerowany schemat odrzuca poprawne dane?

Niemal zawsze dlatego, że każdy klucz oznaczono jako wymagany albo dlatego, że pole będące w próbce null-em otypowano jako null zamiast jako dopuszczające null. Oba to artefakty wnioskowania z jednego dokumentu i oba trzeba poprawić ręcznie.

Jak uzyskać schemat, który naprawdę się przyda?

Potraktuj wynik jako pierwszą wersję roboczą. Rozszerz pola dopuszczające null do unii, wyjmij naprawdę opcjonalne klucze z required, dodaj format i enum tam, gdzie znasz ograniczenie, i sprawdź schemat na kilku prawdziwych dokumentach, a nie tylko na tym, z którego go wygenerowałeś.

Generator schematów JSON

Wklej JSON i wygeneruj JSON Schema.

Wejściowy JSON

Wszystkie obliczenia wykonywane są lokalnie w przeglądarce. Dane nie są wysyłane na serwer.

Wyniki mają charakter informacyjny. Potwierdź je w innych źródłach.

Wnioskowanie JSON Schema i to, czego wnioskowanie nie wie

Schemat wygenerowany z próbki opisuje tę próbkę, a nie twój model danych. Trafia w kształt, a mija się z intencją, bo pojedynczy przykład nie powie, które pola są opcjonalne, które wartości to wyliczenia, a które null-e coś znaczą.

Jak to działa

Przechodzi po JSON-ie i emituje typ dla każdej wartości: obiekt, tablica, napis, liczba, wartość logiczna albo null.
Oznacza jako wymagany każdy klucz obecny w próbce, bo tylko tyle wynika z jednego przykładu.
Schodzi rekurencyjnie w obiekty zagnieżdżone i wnioskuje typy elementów tablic z tego, co znajdzie.

wnioskowane typy
  "tekst"     → string
  42          → number (integer, gdy brak części ułamkowej)
  true        → boolean
  null        → null   (a nie "opcjonalne")
  [ ... ]     → array z wywnioskowanymi elementami
  { ... }     → object z właściwościami

required = każdy klucz widziany w próbce

Przykład z liczbami

Wnioskowanie z {"id": 1, "name": "Ada", "email": null, "tags": ["a", "b"]}.

id → integer, name → string
email → null, co jest niemal na pewno błędne: powinno być ["string", "null"]
tags → tablica napisów
wszystkie cztery klucze oznaczone jako wymagane
brak maxLength, brak format, brak enum — nic z tego nie widać w jednej próbce

Strukturalnie poprawny schemat, który odrzucałby poprawne dane. Pole email otypowane jako null przyjmuje wyłącznie null, a oznaczenie wszystkich kluczy jako wymaganych odrzuca każdy rekord, w którym któregoś brakuje.

Jak czytać wynik

Null w próbce nie oznacza, że typem jest null. Prawie zawsze oznacza, że pole może być puste, więc poprawnym typem jest unia w rodzaju ["string", "null"]. Wnioskowanie nie odróżnia tych przypadków i zawsze zgaduje węższy.
Wszystko trafia do required, bo nieobecność jest niewidoczna. Podaj kilka różnych dokumentów, a suma kluczy pokaże prawdziwy kształt — przy jednej próbce opisujesz tylko ten dokument.
Formaty, wyliczenia i ograniczenia są dla wnioskowania niewidoczne. Adres e-mail, UUID, data i dowolny napis wyglądają identycznie; dodanie format, enum, minimum i maxLength to praca, która zamienia kształt w kontrakt.
Tablice są najsłabszym punktem wnioskowania. Pusta tablica nie daje żadnego typu elementu, a tablica typów mieszanych zwykle znaczy, że próbka jest niereprezentatywna, a nie że pole naprawdę przyjmuje cokolwiek.

Częste pytania

Dlaczego mój wygenerowany schemat odrzuca poprawne dane?: Niemal zawsze dlatego, że każdy klucz oznaczono jako wymagany albo dlatego, że pole będące w próbce null-em otypowano jako null zamiast jako dopuszczające null. Oba to artefakty wnioskowania z jednego dokumentu i oba trzeba poprawić ręcznie.
Jak uzyskać schemat, który naprawdę się przyda?: Potraktuj wynik jako pierwszą wersję roboczą. Rozszerz pola dopuszczające null do unii, wyjmij naprawdę opcjonalne klucze z required, dodaj format i enum tam, gdzie znasz ograniczenie, i sprawdź schemat na kilku prawdziwych dokumentach, a nie tylko na tym, z którego go wygenerowałeś.

Źródła

JSON Schema Specification