Is your feature request related to a problem? Please describe. Now the tool cli API supports only single file as input. I'd suggest to extend it to have directory as as option. This would help with generating models from json-schema (or may be even from other formats as well). For example, let's have the following schemas (see below).

Since the tool doesn't support directory as input I make a separate CLI call for both file. In that case the output would have:

• model generated from object.json for Object
• model generated from object.json for referenced Metadata
• model generated from metadata.json

Even more, if we have 2 and more files, which, like object.json refer to the same external reference, we will have copy of the model in every output file.

// object.json
{
  "$schema": "http://json-schema.org/schema#",
  "type": "object",
  "title": "Object",
  "properties": {
    "metadata": {
      "$ref": "metadata.json#/"
    }
  },
  "required": [
    "metadata",
  ]
}

// another file in the same dir
{
  "$schema": "http://json-schema.org/schema#",
  "type": "object",
  "title": "Object",
  "properties": {
    "somefield": {
      "type": "integer"
    }
  },
  "required": [
    "metadata",
  ]
}

Describe the solution you'd like In the described case I would like to avoid duplicated models output for the references.

Describe alternatives you've considered May be, another alternative is to recursively call the datamodel-codegen in case of reference to the external file (then even if we had made few calls to generate the same reference from different referees we would just override the previous result in a separate file, instead of generating inline pydantic model-duplicate).

Additional context Add any other context or screenshots about the feature request here.

Hi,

first of all thank you for the project this looks really interesting!

Is your feature request related to a problem? Please describe. All the versions in requirements are pinpoint which might cause version conflicts when using this with other packages e.g. fastapi.

Describe the solution you'd like Instead of pinpoint the pydantic version make it lower bound pydantic[email]>=1.5.1

Describe the bug It is not extending all the mentioned classes in the allOf attribute of the schema.

To Reproduce I am running this on the directory: https://github.com/AnalyticalGraphicsInc/czml-writer/tree/master/Schema. But it does not inherit all the classes as I mentioned above. For example, one of the schemas is as follows,

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "https://analyticalgraphicsinc.github.io/czml-writer/Schema/Color.json",
    "title": "Color",
    "description": "A color. The color can optionally vary over time.",
    "allOf": [
        { "$ref": "InterpolatableProperty.json" },
        { "$ref": "DeletableProperty.json" },
        { "$ref": "ValueProperties/RgbaValueProperty.json" },
        { "$ref": "ValueProperties/RgbafValueProperty.json" },
        { "$ref": "ValueProperties/ReferenceValueProperty.json" }
    ],
    "type": [
        "array",
        "object"
    ],
    "items": {
        "$ref": "#"
    },
    "properties": {
        "rgba": {
            "$ref": "Values/RgbaValue.json",
            "description": "The color specified as an array of color components `[Red, Green, Blue, Alpha]` where each component is an integer in the range 0-255."
        },
        "rgbaf": {
            "$ref": "Values/RgbafValue.json",
            "description": "The color specified as an array of color components `[Red, Green, Blue, Alpha]` where each component is a double in the range 0.0-1.0."
        },
        "reference": {
            "$ref": "Values/ReferenceValue.json",
            "description": "The color specified as a reference to another property."
        }
    }
}

It generates the class as follows:

# generated by datamodel-codegen:
#   filename:  Color.json
#   timestamp: 2021-03-29T05:46:25+00:00

from __future__ import annotations

from typing import Optional

from pydantic import BaseModel, Field

from . import Cylinder, LabelStyle


class Color(BaseModel):
    """
    A color. The color can optionally vary over time.
    """

    rgba: Optional[Cylinder.RgbaValue] = Field(
        None,
        description='The color specified as an array of color components `[Red, Green, Blue, Alpha]` where each component is an integer in the range 0-255.',
    )
    rgbaf: Optional[Cylinder.RgbafValue] = Field(
        None,
        description='The color specified as an array of color components `[Red, Green, Blue, Alpha]` where each component is a double in the range 0.0-1.0.',
    )
    reference: Optional[LabelStyle.ReferenceValue] = Field(
        None, description='The color specified as a reference to another property.'
    )

Expected behavior It should have inherited the classes DeletableProperty and InterpolatableProperty

Additional context Those classes have been generated and are residing in the same directory. It's just that they are not being imported and inherited.

Describe the bug

When using type: string in combination with nullable: true in an OpenAPI specification, the resulting type should be Optional[str] but it is not.

To Reproduce

Example schema:

openapi: 3.0.3
info:
  version: 1.0.0
  title: testapi
  license:
    name: proprietary
servers: []
paths: {}
components:
  schemas:
    TopLevel:
      type: object
      properties:
        cursors:
          type: object
          properties:
            prev:
              type: string
              nullable: true
          required:
          - prev
      required:
      - cursors

Used commandline:

$ env/bin/datamodel-codegen --input spec.yaml --output test.py

Expected behavior

The generated class should be

class Cursors(BaseModel):
    prev: Optional[str]

but currently it is:

class Cursors(BaseModel):
    prev: str

Version:

• OS: Linux
• Python version: 3.9
• datamodel-code-generator version: 0.7.0

Hello,

thanks again for this piece of software. I have a little project for that I would like to use the code generator. The basic idea is the following:

1. parse existing data models from https://www.schemastore.org/json/ or ontologies in the form of *.ttl or *.owl to create pydantic models.
2. create instances of my models from a large dictionary of data
3. validate the data via pydantic, at least with the build-in validators
4. store the data in a mongodb based RestAPI, using the pydantic serialization mechanisms.

As a first step, I was playing around with the data models from https://www.schemastore.org/json expecting them to work out of the box. However, I faced several issues with this:

1. In most cases the schemas provide titles that cannot directly be parsed as ClassName. This is solvable by creating my own ClassName. By somehow pre-parsing the file and generate my own Name and set it to the parser using the data model generator with CLI. However, in most cases the "Top-Layer" Model does not even be created because one might even be more interested in the underlying submodels the schema consists of.
2. Furthermore, I experienced that several types are not parsed correctly. Maybe it would be good to use 'Any' as default type instead of simply failing.

Suggestion to solve:

• Writing a test that parses a randomized subset of https://www.schemastore.org/json. This would at least provide sophisticated testing data schemas to test for integrity.

Thanks for your help

Cheers

Describe the bug Given the type Union[int, List[A], B]:

• A is treated as Any
• B class is generated empty with extra=allowed

To Reproduce

Example schema:

{"$schema":"http://json-schema.org/draft/2019-09/schema#", "oneOf":[{"type":"integer","$comment":"int"},{"type":"array","items":{"type":"object","properties":{"key":{"type":"object","properties":{"address":{"type":"string","$comment":"address"},"nat":{"type":"string","$comment":"nat"}},"required":["address","nat"],"additionalProperties":false,"$comment":"pair"},"value":{"type":"string","$comment":"nat"}},"required":["key","value"],"additionalProperties":false}}],"$comment":"big_map"}

Used commandline:

$ datamodel-codegen --input schema.json --output schema.py

Expected behavior All the oneOf sub-schemas are parsed recursively.

Version:

• OS: Ubuntu 18
• Python version: 3.9
• datamodel-code-generator version: 0.10.2

Hey @koxudaxi!

very nice package, thanks a lot for your work on this! I'd like to use it and I am already using the latest version of isort and black. It would be nice if the datamodel-code-generator is compatible with this which is whiy I make this PR.

From my perspective, this PR can be merged if the CI passes.

Is your feature request related to a problem? Please describe.

Environment

datamodel-code-generator==0.9.3

Scenario

Wanted to generate pydantic models from docker engine API.

datamodel-codegen --url "https://converter.swagger.io/api/convert?url=https://docs.docker.com/engine/api/v1.30.yaml"

Note that docker engine api uses openapi 2.0 spec. Therefore, I used converter.swagger.io to translate it into 3.0.0.

Error message

Traceback (most recent call last):
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/__main__.py", line 424, in main
    strict_types=config.strict_types,
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/__init__.py", line 311, in generate
    results = parser.parse()
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/base.py", line 386, in parse
    self.parse_raw()
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/openapi.py", line 34, in parse_raw
    [*path_parts, '#/components', 'schemas', obj_name],
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/jsonschema.py", line 997, in parse_raw_obj
    self.parse_obj(name, JsonSchemaObject.parse_obj(raw), path)
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/jsonschema.py", line 1002, in parse_obj
    self.parse_object(name, obj, path)
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/jsonschema.py", line 624, in parse_object
    fields=self.parse_object_fields(obj, path),
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/jsonschema.py", line 571, in parse_object_fields
    field_type = self.parse_enum(field_name, field, [*path, field_name])
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/parser/jsonschema.py", line 820, in parse_enum
    name=self.model_resolver.get_valid_name(field_name),
  File "<my_path>/python3.7/site-packages/datamodel_code_generator/reference.py", line 362, in get_valid_name
    if name[0] == '#':
IndexError: string index out of range

Cause

The docker engine openapi spec defines a schema with an Enum that contains an empty string:

    RestartPolicy:
      type: object
      properties:
        Name:
          type: string
          description: ...
          enum:
          - ""   # here
          - always
          - unless-stopped
          - on-failure

It seems that get_valid_name cannot handle empty strings.

Describe the solution you'd like

I've tested the following workaround by changing the function get_valid_name as below.

def get_valid_name(self, name: str, camel: bool = False) -> str:
    if not name:    # +
        return "_"     # +
    if name.isidentifier():
        return name
    if name[0] == '#':
        name = name[1:]   # note that original error is caused here. 
    ...

The resulting enum is

class Name(Enum):
    """
        - Empty string means not to restart
    - `always` Always restart
    - `unless-stopped` Restart always except when the user has manually stopped the container
    - `on-failure` Restart only when the container exit code is non-zero

    """

    _ = ''
    always = 'always'
    unless_stopped = 'unless-stopped'
    on_failure = 'on-failure'

Describe alternatives you've considered

If we are targeting python 3.8 and above, this issue can be easily mitigated by using --enum-field-as-literal all. Therefore this issue can be resolved by allowing --enum-field-as-literal option in python 3.7 by importing Literal from typing_extensions.

When trying to convert file data.json to model.py, I get a keyerror on line 171 of jsonschema.py when the type in types is 'array'.

To Reproduce

Example schema:

Describe the bug I am not yet sure how to reproduce which state, as I have two different observation:

Example 1:

Generated code:

from ...apimachinery.pkg.apis.meta import v1
from ..core import v1

(from: https://github.com/FlorianLudwig/pdk8s/blob/e9b5903c4f8cf584fe60a4a84709a42f7e63b771/pdk8s/gen/io/k8s/api/networking/v1beta1.py#L12)

Example 2:

Generated code:

from ...apimachinery.pkg.apis.meta import v1
from ..core import v1 as v1_1

(from: https://github.com/FlorianLudwig/pdk8s/blob/e9b5903c4f8cf584fe60a4a84709a42f7e63b771/pdk8s/gen/io/k8s/api/extensions/v1beta1.py)

In this example, the second import is renamed to avoid the collision but the references are not. Resulting in code trying to access module members that are in v1_1 but refer to v1. (Example)

Expected behavior

The second example is a step in the right direction (or maybe import more of the package name, in this example meta.v1 instead of just v1). But the references must be updated.

Version:

• datamodel-code-generator: git master

Describe the bug Parser can not resolve classes when using $ref if the path is nested even though the reference is a valid json pointer.

File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\__main__.py", line 281, in main
    generate(
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\__init__.py", line 259, in generate
    results = parser.parse()
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\parser\base.py", line 332, in parse
    _, sorted_data_models, require_update_action_models = sort_data_models(
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\parser\base.py", line 110, in sort_data_models
    return sort_data_models(
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\parser\base.py", line 110, in sort_data_models
    return sort_data_models(
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\parser\base.py", line 110, in sort_data_models
    return sort_data_models(
  [Previous line repeated 97 more times]
  File "c:\users\sonali.ingale\appdata\local\programs\python\python39\lib\site-packages\datamodel_code_generator\parser\base.py", line 158, in sort_data_models
    raise Exception(f'A Parser can not resolve classes: {unresolved_classes}.')
Exception: A Parser can not resolve classes: [class: Person references: {'Dog', 'Cat'}]

To Reproduce

Example schema:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Person",
    "type": "object",
    "properties": {
        "name": {
            "title": "name",
            "type": "string"
        },
        "pet": {
            "title": "pet",
            "type": "object",
            "oneOf": [
                {
                    "$ref": "#/definitions/Pets/Cat"
                },
                {
                    "$ref": "#/definitions/Pets/Dog"
                }
            ]
        }
    },
    "definitions": {
        "Pets": {
            "Cat": {
                "title": "Cat",
                "type": "object",
                "required": [
                    "pet_type",
                    "hunts",
                    "age"
                ],
                "properties": {
                    "pet_type": {
                        "enum": [
                            "Cat"
                        ]
                    },
                    "hunts": {
                        "type": "boolean"
                    },
                    "age": {
                        "type": "string"
                    }
                }
            },
            "Dog": {
                "title": "Dog",
                "type": "object",
                "required": [
                    "pet_type",
                    "bark",
                    "breed"
                ],
                "properties": {
                    "pet_type": {
                        "enum": [
                            "Dog"
                        ]
                    },
                    "bark": {
                        "type": "boolean"
                    },
                    "breed": {
                        "type": "string"
                    }
                }
            }
        }
    },
    "additionalProperties": false
}

Used commandline:

$ datamodel-codegen --input pets.json --input-file-type=jsonschema --output pets.py

Expected behavior I was expecting following things which is working when I do not encapsulate "Cat" and "Dogs" inside "Pet".

• Create the classes "Cat" and "Dog"
• Add "pet" attribute with Union of "Cat" and "Dog"

Version:

• windows
• Python version: 3.9.0
• datamodel-code-generator version:0.6.18

Additional context I tried to pull the code and run this example but I am getting the same error. I have few large schemas which are encapsulating references for readability. After editing the schema according to datamodel-code-generator, it works wonderfully 👍 . Thanks for this module.

Describe the bug

I am trying to produce pydantic models from a JSONSchema file I have. When I try to do this, the process never finishes and just accumulates memory without end. I let it run for a while and it ended up taking up 8+GB of memory. The schema itself is a good handful of megabytes with probably over 10,000 discrete components, which could be a problem, but I believe it should stop eventually.

Eventually this stack trace is produced with a RecursionError:

Traceback (most recent call last):
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\__main__.py", line 626, in main
    generate(
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\__init__.py", line 384, in generate
    results = parser.parse()
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\base.py", line 475, in parse
    self.parse_raw()
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1270, in parse_raw
    self._resolve_unparsed_json_pointer()
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1294, in _resolve_unparsed_json_pointer
    self._resolve_unparsed_json_pointer()
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1294, in _resolve_unparsed_json_pointer
    self._resolve_unparsed_json_pointer()
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1294, in _resolve_unparsed_json_pointer
    self._resolve_unparsed_json_pointer()
  [Previous line repeated 957 more times]
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1290, in _resolve_unparsed_json_pointer
    self.parse_json_pointer(self.raw_obj, reserved_ref, path_parts)
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1306, in parse_json_pointer
    self.parse_raw_obj(
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 1213, in parse_raw_obj
    self.parse_obj(name, JsonSchemaObject.parse_obj(raw), path)
  File "pydantic\main.py", line 526, in pydantic.main.BaseModel.parse_obj
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 208, in __init__
    super().__init__(**data)
  File "pydantic\main.py", line 340, in pydantic.main.BaseModel.__init__
  File "pydantic\main.py", line 1076, in pydantic.main.validate_model
  File "pydantic\fields.py", line 886, in pydantic.fields.ModelField.validate
  File "pydantic\fields.py", line 1021, in pydantic.fields.ModelField._validate_mapping_like
  File "pydantic\fields.py", line 1094, in pydantic.fields.ModelField._validate_singleton
  File "pydantic\fields.py", line 884, in pydantic.fields.ModelField.validate
  File "pydantic\fields.py", line 1094, in pydantic.fields.ModelField._validate_singleton
  File "pydantic\fields.py", line 884, in pydantic.fields.ModelField.validate
  File "pydantic\fields.py", line 1101, in pydantic.fields.ModelField._validate_singleton
  File "pydantic\fields.py", line 1148, in pydantic.fields.ModelField._apply_validators
  File "pydantic\class_validators.py", line 318, in pydantic.class_validators._generic_validator_basic.lambda13
  File "pydantic\main.py", line 711, in pydantic.main.BaseModel.validate
  File "C:\Users\Spencer\repos\redacted\venv\lib\site-packages\datamodel_code_generator\parser\jsonschema.py", line 208, in __init__
    super().__init__(**data)
  File "pydantic\main.py", line 340, in pydantic.main.BaseModel.__init__
  File "pydantic\main.py", line 1076, in pydantic.main.validate_model
  File "pydantic\fields.py", line 884, in pydantic.fields.ModelField.validate
  File "pydantic\fields.py", line 1101, in pydantic.fields.ModelField._validate_singleton
  File "pydantic\fields.py", line 1148, in pydantic.fields.ModelField._apply_validators
  File "pydantic\class_validators.py", line 318, in pydantic.class_validators._generic_validator_basic.lambda13
  File "pydantic\validators.py", line 61, in pydantic.validators.str_validator
RecursionError: maximum recursion depth exceeded while calling a Python object

The schema is too large to put in the issue, but it can be found in this gist.

Used commandline:

$ datamodel-codegen  --input problem.json --input-file-type jsonschema --output model.py

Expected behavior

The expectation is that the model generation eventually completes.

Version:

• OS: Windows 10 22H2 (build 19045.2364)
• Python version: 3.10.2
• datamodel-code-generator version: 0.14.1

Additional context

The schema itself was created by dynamically generating pydantic models and dumping model.json_schema(). Not sure if that's relevant, but in my mind I guess it's not out of the realm of possibility that this could matter.

Bumps mkdocs-material from 8.5.11 to 9.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps coverage from 7.0.1 to 7.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Is your feature request related to a problem? Please describe. We need to have correct support of discriminator object type. At the moment the behavior differs from the required one, instead of adding the discirminator attribute to the field, a dictionary with links to schemas is created:

# wrong autogenerated code
Field(
    ...,
    discriminator={
                "propertyName": "type",
                "mapping": {
                    "type1": "#/components/schemas/Schema1",
                    "type2": "#/components/schemas/Schema2",
                    "type3": "#/components/schemas/Schema3",
                },
            },
)

Describe the solution you'd like As an example, take a look at a piece of the api specification and the resulting code:

OpenAPI

    Schema:
      oneOf:
        - $ref: "#/components/schemas/Schema1"
        - $ref: "#/components/schemas/Schema2"
        - $ref: "#/components/schemas/Schema3"
      discriminator:
        propertyName: type
        mapping:
          type1: "#/components/schemas/Schema1"
          type2: "#/components/schemas/Schema2"
          type3: "#/components/schemas/Schema3"

Generated pydantic model

class OptimizationSimulationParametersSchema(BaseModel):
    __root__: Union[
        Schema1,
        Schema2,
        Schema3,
    ] = Field(..., discriminator="type")

Additional info Link to specification https://spec.openapis.org/oas/v3.0.3#discriminator-object

Describe the bug When patternProperties is inside a reference object, the generated classes are wrongly generated.

In this example, I created a json schema where:

• KeyWithExplicitPatternProperties has explicit patternProperties
• KeyWithPatternPropertiesByReference is the same as KeyWithExplicitPatternProperties, but it uses a $ref to define the same object as KeyWithExplicitPatternProperties
• SomeOtherBoringReference is just a boring $ref with a trivial object that is correctly parsed.

This way we can see that KeyWithPatternPropertiesByReference fails to correctly create the class. It looks related to the $ref invocation since everything else is the same.

To exemplify, I created a patternProperty that makes a json valid when the key is one letter and one char, like so:

{
	"KeyWithExplicitPatternProperties": {
		"a1": "foo"
	},
	"KeyWithPatternPropertiesByReference": {
		"a2": "bar"
	},
	"SomeOtherBoringReference": {
		"timeout": 42
	}
}

To Reproduce

Example schema:

{
  "$defs": {
    "stt": {
      "additionalProperties": false,
      "description": "STT properties allows to configure how the user voice is converted to text",
      "properties": {
        "timeout": {
          "title": "STT Timeout",
          "type": "number"
        }
      },
      "title": "Speech to text Settings",
      "type": "object"
    },
    "textResponse": {
      "additionalProperties": false,
      "type": "object",
      "patternProperties": {
        "^[a-z]{1}[0-9]{1}$": {
          "phoneNumber": {
            "additionalProperties": false,
            "type": "number"
          }
        }
      }
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema",
  "additionalProperties": false,
  "description": "The root schema comprises the entire JSON document",
  "properties": {
    "KeyWithExplicitPatternProperties": {
      "additionalProperties": false,
      "type": "object",
      "patternProperties": {
        "^[a-z]{1}[0-9]{1}$": {
          "phoneNumber": {
            "additionalProperties": false,
            "type": "number"
          }
        }
      }
    },
    "KeyWithPatternPropertiesByReference": {
      "$ref": "#/$defs/textResponse"
    },
    "SomeOtherBoringReference": {
      "$ref": "#/$defs/stt"
    }
  },
  "title": "SomeSchema Schema",
  "type": "object"
}

Used commandline:

$ datamodel-codegen --use-double-quotes

Expected behavior

I would expect that KeyWithPatternPropertiesByReference is created the same way as KeyWithExplicitPatternProperties

Version:

• OS: Fedora release 37 (Thirty Seven)
• Python version: 3.10.8
• datamodel-code-generator version: 0.14.0

Additional context

Generated classes

# generated by datamodel-codegen:
#   filename:  v1.json
#   timestamp: 2022-12-13T16:49:55+00:00

from __future__ import annotations

from typing import Any, Dict, Optional

from pydantic import BaseModel, Extra, Field, constr


class Stt(BaseModel):
    class Config:
        extra = Extra.forbid

    timeout: Optional[float] = Field(None, title="STT Timeout")


class TextResponse(BaseModel):
    pass

    class Config:
        extra = Extra.forbid


class ConversationV1(BaseModel):
    class Config:
        extra = Extra.forbid

    KeyWithExplicitPatternProperties: Optional[Dict[constr(regex=r"^[a-z]{1}[0-9]{1}$"), Any]] = None
    KeyWithPatternPropertiesByReference: Optional[TextResponse] = None
    SomeOtherBoringReference: Optional[Stt] = None

To test, we can see that:

valid_object1 = {"KeyWithExplicitPatternProperties": {"a1": "foo"}, "SomeOtherBoringReference": {"timeout": 42}}

conv1 = ConversationV1.parse_obj(valid_object1)

valid_object2 = {
    "KeyWithExplicitPatternProperties": {"a1": "foo"},
    "KeyWithPatternPropertiesByReference": {"a2": "bar"},
}

conv2 = ConversationV1.parse_obj(valid_object2)

conv1 is correctly parsed, but conv2 throws an Exception:

  File "/home/luminoso/scotty/bitbucket/stagger/src/gendatamodels/v1_gen.py", line 44, in <module>
    conv2 = ConversationV1.parse_obj(valid_object2)
  File "pydantic/main.py", line 526, in pydantic.main.BaseModel.parse_obj
  File "pydantic/main.py", line 342, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 1 validation error for ConversationV1
KeyWithPatternPropertiesByReference -> a2
  extra fields not permitted (type=value_error.extra)

Which is expected for the generated classes, but not for the schema.

I also validated the schema in https://www.jsonschemavalidator.net/

Thanks for a great project

Describe the bug Argument 'discriminator' has incorrect type (expected str, got dict) The structure of dict generated and assigned to the discriminator :

my_project/models/fhir.py:560: in Model
    ] = Field(
E   TypeError: Argument 'discriminator' has incorrect type (expected str, got dict)

To Reproduce

wget https://build.fhir.org/fhir.schema.json.zip
unzip fhir.schema.json.zip
datamodel-codegen --input fhir.schema.json --input-file-type jsonschema --output fhir.py

sed -n '556, 570 p' fhir.py 

>>>

        Transport,
        ValueSet,
        VerificationResult,
        VisionPrescription,
    ] = Field(
        ...,
        description='see http://hl7.org/fhir/json.html#schema for information about the FHIR Json Schemas',
        discriminator={
            'propertyName': 'resourceType',
            'mapping': {
                'Account': '#/definitions/Account',
                'ActivityDefinition': '#/definitions/ActivityDefinition',
                'ActorDefinition': '#/definitions/ActorDefinition',
                'AdministrableProductDefinition': '#/definitions/AdministrableProductDefinition',
                'AdverseEvent': '#/definitions/AdverseEvent',

Version:

$ pip freeze | grep code
datamodel-code-generator==0.14.0
$ pip freeze | grep pydantic
pydantic==1.10.2
$ python3 --version
Python 3.9.12