The Ruby code that is generated copies numerous methods into every
model. This creates bloat both in file size and run-time memory usage.
This commit introduces a base class for all models to store common
methods. This commit's focus is only on static methods that do not
change between models.
* Expose mtls config params in python template
* Expose certFile and keyFile configuration items to support mtls in php generated client
* Regenerate of examples
* [Julia] Fix docstring parameter formatting with backticks
Wrap parameter names in backticks in generated Julia client docstrings
to prevent markdown from misinterpreting underscores as italic formatting.
This fixes an issue where parameter names like `pet_id`, `api_key`, and
`additional_metadata` would render incorrectly in documentation, with
underscores being treated as markdown italic markers instead of literal
characters.
Related issue: JuliaComputing/OpenAPI.jl#72
* Also wrap data types and return types in backticks
* Regenerate Julia client samples with backticked docstrings
* [Julia] Add backticks to all markdown documentation templates
Extend backtick formatting to markdown documentation templates for
both Julia client and server generators. This ensures consistent
markdown rendering of identifiers with underscores.
Changes:
- julia-client/api_doc.mustache: Add backticks to function signatures,
parameter names, types, and return types in markdown API docs
- julia-server/api_doc.mustache: Same changes for server API docs
- julia-client/model_doc.mustache: Add backticks to property names and
types in markdown model documentation
- julia-server/model_doc.mustache: Same changes for server model docs
All generated markdown files now properly display identifiers like
`pet_id`, `Custom_Type`, `update_pet_with_form` with literal
underscores instead of broken italic formatting.
Related to JuliaComputing/OpenAPI.jl#72
* allow configuring jackson, remove jackson import if disabled
* do not generate root resource or application file if generating interface
* change template files to remove jackson if disabled
* updated samples and docs as required by PR checklist
* [rust-axum] Make discriminator field name camelCase
* [rust-axum] Give polymorphic enum values a serde alias using the mapping keys if available
* update samples
* update test file checksum
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
- nullable is only supported for MultipartFile. However, Array<MultipartFile> could be also nullable
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
Update kotlin-spring-additionalproperties samples
* [python-fastapi] Fix: Skip sorting of path operations (#22163)
Make use of helpful code added in
243f501aef to skip sorting of path
parameters. In FastAPI, order matters, see link for details:
https://fastapi.tiangolo.com/tutorial/path-params/?h=path#order-matters
Issue: https://github.com/OpenAPITools/openapi-generator/issues/22163
* Update samples after previous commit
Reading comprehension is hard. I missed the part of step 3 where
samples would be updated in response to the change I had previous
submitted.
Via this commit, update samples to match expectations. The order of
various endpoint implementations is now changed in the sample, matchcing
the order in the yaml files that created them.
Previously, if an API endpoint was marked deprecated, this fact was not
reflected in the generated Rust clients using the reqwest library. We
want to know exactly when our client code is using a deprecated endpoint,
so marking the corresponding functions with the `#[deprecatd]` attribute
would be very helpful. Uses of the endpoint would then be picked up by
linters so that we can react.
This adds a line to the template which marks functions generated from
deprecated endpoints with the `#[deprecated]` attribute.
This does not touch any of the other client generators for Rust or any
other language, since they are out of scope for our needs.
Co-authored-by: Bradford Hovinen <bho@qwello.eu>
