Support for generating non python code

[andersesbensen]

I’m looking for a way to generate C++ code and other code and documentation from json schemas. I saw that this project allows for custom Jinja templates. So I thought that I might be able to use your generator. However it seems that the way things are now, the templates must generate python code at a formatter is handling the generated code. Also field variable type_ hint is a derived pydantic type.

Would it be feasible to change the generator into a more generic generator which could be used to generate arbitrary transformations of JSON schemas?

I want to make C++ code, Rust code, documentation and even UI’s from a schema.

Any thoughts on this?

[koxudaxi]

@andersesbensen

Would it be feasible to change the generator into a more generic generator which could be used to generate arbitrary transformations of JSON schemas?

Yes, if it is considered valuable enough.

I have been thinking about something similar for years.

First of all, I created this tool to create a Pydantic model from OpenAPI. However, I did not include Pydantic in the package name to allow for diversity in input and output formats.
As a result, it now supports Python TypeDict, dataclasses and msgspec.

However it seems that the way things are now, the templates must generate python code at a formatter is handling the generated code

From the beginning, formatting has been optional at the method level, so it can easily be disabled by command options or output format.

Of course, the module structure is different from Python, so some refactoring is required to support other languages.

Also field variable type_ hint is a derived pydantic type.

This tool parses the schema and generates an abstract object called datamodel.
This is the relationship between the class name and the fields, and I think it is probably possible to generate objects that hold a similar structure, such as kotlin's data classes or TypeScript's Zod.
Also, from the design phase, I did not keep datamodel as a Python AST or CST in order to preserve the possibility of outputting non-Python code.

This project started as a small tool for me, and even after the number of users increased, I did not do any major refactoring for compatibility.
For example, I am thinking that it might be nice to rewrite it in Rust for execution speed and a single binary. However, it is not clear that the code generator needs that much performance, and since it provides a docker image, I may not feel that not having a single binary is a disadvantage in many use cases.
Besides, I believe it gets a lot of pull requests by being written in Python; I can't really imagine many people casually giving pull requests to Rust's complex implementation.
Even if you are not a Python user, it is far easier to understand Python syntax than Rust.

What do you think of the above thoughts?

[koxudaxi]

@andersesbensen

I think the Python get_valid_name applies to more or less all languages I can think of.

OK, it's good.

Could the JSON to C++ primitive type map be a template in itself?

Interesting suggestion.
I feel it would work well for primitive types and no default value.
However, I am not sure if it is possible to express everything in the template, since the output often refers to another model or involves multiple elements, such as Optional[Union[List[Optional[str]], int, float]]. (Even if it could, I fear that it would become so complex that no one would be able to understand it.)
However, I agree with the idea of having a property as an open interface.

Regarding the formatter, I would argue that it should not be part of the generation at all, as the formatter is language specific, for rust code, I would use rustfmt, for C++ code I would use clang-format and for markdown, a third tool would be used.

I agree. the cli provides the formatter for Python by default, but it's ok it may not provide formatter for other languages.
Of course, calling rustfmt or similar in a sub-process as an option is not a bad idea.

[andersesbensen]

I'm trying to play around with the code and there is something I don't quite understand, If I add

    @property
    def foo(self) -> str:
        return self.data_type.is_list

to DataModelFieldBase and use print the field in a template like this:

    {%- for field in fields %}
        {{ field.foo }}
    {%- endfor -%}

It always returns False?

[koxudaxi]

@andersesbensen
Can you share the example input?

[andersesbensen]

This is my model

{
    "$id": "https://example.com/person.schema.json",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "ProjectSettings",
    "type": "object",
    "description": "Main project settings",

    "properties": {
        "batchmode": {
            "type": "boolean",
            "default": "false",
            "description": "Run though the calculations without stopping. This is typically for command line usage"
        },
        "import_settings": {
            "type"  :"array",
            "items": {
                "$ref": "#/definitions/ImportSettings"
            }
        }
    },
    "required": [
        "import_settings"
    ],
    "definitions": {
        "ImportSettings": {
            "type": "object",
            "properties": {
                "file_name": {
                    "type": "string"
                }
            }
        }
    }
}

[koxudaxi]

@andersesbensen
I guess you can access the attribute by self.data_type.data_types[0].is_list
We should refactor the case.

datamodel-code-generator/datamodel_code_generator/types.py

Lines 448 to 449 in 2a3d27d

	elif len(self.data_types) == 1:
	type_ = self.data_types[0].type_hint