juhaku / utoipa

Simple, Fast, Code first and Compile time generated OpenAPI documentation for Rust
Apache License 2.0
2.46k stars 191 forks source link

Supporting sqlx Json<T> #952

Open ElysaSrc opened 5 months ago

ElysaSrc commented 5 months ago

I think it'd be nice to support (behind a feature flag) the Json<T> because, currently the typing is lost on this element on the OpenAPI generated file.

juhaku commented 1 month ago

@ElysaSrc Could you elaborate bit more how you would like the support to be? How it should behave?

ElysaSrc commented 1 month ago

@ElysaSrc Could you elaborate bit more how you would like the support to be? How it should behave?

Currently I must annotate all Json fields of my struct that is requested though sqlx with the inner type, I was wondering if maybe it could be inferred so when we have a json it directly infer a T type in the openapi scheme ?

juhaku commented 1 month ago

Okay, so it should infer the inner type. This needs some looking into to assess what can be done there.

juhaku commented 4 weeks ago

@ElysaSrc All I get is:

error[E0412]: cannot find type `Json` in module `sqlx::types`
   --> utoipa/src/lib.rs:650:45
    |
650 | impl<T: ToSchema> ToSchema for sqlx::types::Json<T> where sqlx::types::Json<T>: PartialSchema {}
    |                                             ^^^^ not found in `sqlx::types`

error[E0412]: cannot find type `Json` in module `sqlx::types`
   --> utoipa/src/lib.rs:650:72
    |
650 | impl<T: ToSchema> ToSchema for sqlx::types::Json<T> where sqlx::types::Json<T>: PartialSchema {}
    |                                                                        ^^^^ not found in `sqlx::types`

error[E0412]: cannot find type `Json` in module `sqlx::types`
   --> utoipa/src/lib.rs:745:50
    |
745 | impl<T: ToSchema> PartialSchema for sqlx::types::Json<T> {
    |                                                  ^^^^ not found in `sqlx::types`

With crates dependency:

sqlx = { version = "0.8", default-features = false, features = [
    "json",
], optional = true }

Somehow it does not "find" the type even though it is there and LSP is able to access it anyhow. Does it need some sort of DB to be there before it can actually be used, Should not since the only feature flag that it seemingly requires is the "json" even though it is not explicitly mentioned.

This is quite weird and IMO should not happen, nevertheless it hinders the implementation quite a bit.

Another approach is to implement generic support for anything that seems like a Json<T> so that utoipa would just treat it as a container type and return the schema of wrapped T as is by baking this support functionality to utoipa-gen. Though I am not sure whether this would have some unwanted side effects with other Json types.

ElysaSrc commented 3 weeks ago

Somehow it does not "find" the type even though it is there and LSP is able to access it anyhow. Does it need some sort of DB to be there before it can actually be used, Should not since the only feature flag that it seemingly requires is the "json" even though it is not explicitly mentioned.

When using sqlx, requests are checked at compile time so it requieres either a cache or a live database, but my guess here is it should not be an issue with just parsing the type ?

This is quite weird and IMO should not happen, nevertheless it hinders the implementation quite a bit.

Another approach is to implement generic support for anything that seems like a Json<T> so that utoipa would just treat it as a container type and return the schema of wrapped T as is by baking this support functionality to utoipa-gen. Though I am not sure whether this would have some unwanted side effects with other Json types.

I'm not aware enough of utoipa internals to have an opinion here, I'd say that the less it messes up with current usages the better it is. Maybe add an optional feature flag for such behavior ?