--field-constraints add decimal points for integers constraints

Describe the bug An option --field-constraints add decimal points for integers constraints

To Reproduce

Example schema:

{
  "type":  "object",
  "properties": {
    "dataSize": {
      "type": "integer",
      "minimum": 10,
      "maximum": 64
    }
  },
}

from __future__ import annotations
from typing import Optional
from pydantic import BaseModel, Field

class Model(BaseModel):
    dataSize: Optional[int] = Field(None, ge=10.0, le=64.0)

Used commandline:

$ datamodel-codegen --input model.json --input-file-type jsonschema --field-constraints > model.py

Expected behavior Expected ge=10 not ge=10.0, same for le dataSize: Optional[int] = Field(None, ge=10, le=64)

[kini]

@koxudaxi Thanks for looking into it. I also found that section of code when investigating this issue. I considered that maybe we can change the type annotations there to

        gt: Optional[Union[int, float]] = ...
        ...

But this idea doesn’t work because of an upstream Pydantic issue, samuelcolvin/pydantic#1423. And even if that worked, it would cause some questionable behavior, e.g.:

{
    "type": "object",
    "properties": {
        "foo": {
            "type": "integer",
            "minimum": 10.0,
            "maximum": 64
        },
        "bar": {
            "type": "number",
            "minimum": 10.0,
            "maximum": 64
        }
    }
}

would result in:

class Model(BaseModel):
    foo: Optional[int] = Field(None, ge=10.0, le=64)
    bar: Optional[float] = Field(None, ge=10.0, le=64)

where instead, one would maybe expect:

class Model(BaseModel):
    foo: Optional[int] = Field(None, ge=10, le=64)
    bar: Optional[float] = Field(None, ge=10.0, le=64.0)

I think ideally the type of gt, ge, lt, and le should match the structural type of the value being constrained. That is, if the schema specifies a value as an integer, its range bounds should be integers, and if the schema specifies a value as a float, its range bounds should be floats.

But this would be difficult because the class Constraints is defined independently from the specific value being constrained.

Also, it is somewhat unclear how to handle this in the case where the schema specifies a union type that contains int and/or float. Right now, we have the following behavior, but I don’t know that it really makes sense, nor am I sure how other consumers of the jsonschema format treat this kind of schema:

{
    "type": "object",
    "properties": {
        "foo": {
            "type": ["integer", "number"],
            "minimum": 10.0,
            "maximum": 64
        }
    }
}

becomes

class Model(BaseModel):
    foo: Optional[Union[int, float]] = Field(None, ge=10.0, le=64.0)

I.e. should 10.0 and 64.0 be used here, or 10 and 64? I don’t know. 😅

[koxudaxi]

I hope the problem was fixed.