Closed alliefitter closed 1 year ago
To help clarify, this is what I'm thinking. I think the arguments in the Choice
object are the only ones that would make sense as global options.
@click.option(
"--dict-option",
multiple=True,
help="Keyword arguments passed to the dict() method of generated Pydantic models. i.e. --dict-option "
"exclude_unset=True --dict-option exclude_none=True",
type=click.Choice([
"exclude_unset=True",
"exclude_defaults=True",
"exclude_none=True"
], case_sensitive=False)
)
And usage would be:
$ openapi-python-generator openapi.json client/ --use-orjson --dict-option exclude_unset=True --dict-option exclude_none=True
I went ahead and implemented this locally and am testing it out in my project for work.
I'd be totally open to a PR that does this. Only thing that we make sure off, is that this is also run through the whole test suite, including Regression issues.
Cool. I updated the tests already, but I haven't touched the regression tests. I'll try to get to that and put up a PR tomorrow. Thanks for the feedback!
Is your feature request related to a problem? Please describe. Not related to a problem, and I'm more than willing to work on the PR.
Describe the solution you'd like I'd like to add a repeated (
multiple=True
) CLI option for arguments passed to Pydantic'sBaseModel.dict()
method, if the maintainers find the same kind of value I do in the feature. The case in which this would be desired is partial updates on a REST API endpoint and wanting to useexclude_unset=True
when sending the request.Describe alternatives you've considered The only alternative I can come up with is editing the generated code which is untenable. EDIT: I guess a more useable alternative would be to ignore null values on the server side, however this would make explicit null values impossible.
Additional context Just wanted to see if this a feature that the maintainers would be interested in.