Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to always inline custom ToSchema impls #962

Open
har7an opened this issue Jun 20, 2024 · 1 comment
Open

Option to always inline custom ToSchema impls #962

har7an opened this issue Jun 20, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@har7an
Copy link

har7an commented Jun 20, 2024

Hello,

I've been trying to find a way to have custom ToSchema impls be inlined automatically in the generated OpenAPI specification. Is that possible and if so, how exactly?

Background

We have a codebase where we define our own DateTime and Duration types since we need them to interact with a few other components of ours and chronos own types don't suit our needs entirely. However, previously we had the chrono feature flag enabled which made our DateTime-type magically appear with the correct schema. On the other hand, I tried defining ToSchema on our own Duration type only to realize that apparently it doesn't have any effect on the generated spec.

Eventually I traced this issue back to impl ToTokensDiagnostics for Type<'_> from utoipa-gen/src/schema_type.rs (I assume that's where it comes from at least), where it appears to be looking at the last component of the fully qualified type name and then decides what to put in.

Obviously this collides with our own types and after removing the chrono flag things work as expected and it picks up our own ToSchema impls.

The Problem

With that settled, I had to realize that all the places in the code where we use a DateTime as part of a struct that has ToSchema derived, the previously inlined schemas have now become references.
That of course requires me to either:

  1. Export the types in the OpenAPI docs as component, or
  2. Annotate all mentions of DateTime with #[inline]

But none of these solutions is entirely satisfying because in either case I lose the description from the associated docstring.

The way things were before, the schema definition of chrono::DateTime was being inlined and when deriving ToSchema on a struct it would complement the docstring of the respective struct field into that schema (unless I'm mistaken). So I knew that my field has type=string, format=date-time and description=....

I had a glance at the source code, but couldn't find any location where this inlining/merging is performed. I haven't written proc-macros before, so I'm a little lost there...

What I'd like to see

Basically I'd like to have a way to always inline a custom ToSchema impl. In addition, if somehow possible, I'd love to see a way to integrate docstrings (of e.g. struct members) into that generated specification in the description field, so we can get something like the default chrono::DateTime can already provide us with.

@juhaku juhaku added the enhancement New feature or request label Sep 10, 2024
@juhaku
Copy link
Owner

juhaku commented Sep 10, 2024

@har7an

We could add possibility to use the schema(inline) attribute on container types as well instead of only on fields and variants.

docstrings (of e.g. struct members) into that generated specification in the description field, so we can get something like the default chrono::DateTime can already provide us with.

In OpenAPI 3.0 there is no description field on ref element. However in OpenAPI 3.1 they have added that field so in 5.0.0 version the description will persist on fields that have a reference as well.

I'd like to have a way to always inline a custom ToSchema impl.

This could be done in a way of global aliases, where the custom DateTime would be set to be alias for chrono::DateTime then naturally it would get inlined. Still this has not been implemented and work has not been started. But some early plans already exist for the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants