Actix: Support specifying types and formats in fields

[mstump]

I'm trying to use paperclip to publish a type like the one below which utilizes types not directly supported such as UUID and NaiveDateTime.

#[table_name = "organizations"]
#[derive(Debug, Serialize, Deserialize, Queryable, Identifiable, AsChangeset)]
#[api_v2_schema]
pub struct Organization {
    pub id: uuid::Uuid,
    pub created_at: NaiveDateTime,
    pub updated_at: NaiveDateTime,
    pub name: String,
    pub description: Option<String>,
}

But it results in these errors.

no function or associated item named `raw_schema` found for type `chrono::NaiveDateTime` in the current scope

Looking through the codebase it looks like it's handled by the macro impl_type_simple and the types in models.rs. Is there a better/easier way to achieve this goal?

[wafflespeanut]

Is there a better/easier way to achieve this goal?

I'm... not sure. Right now, the only way I see forward is to add a feature gate for both uuid and chrono and implement that trait behind those feature gates.

We have a trait (TypedData) for getting the OpenAPI data type and format for types - now this is (or should be) implemented for all basic types. But UUID and NaiveDateTime are foreign types, which OpenAPI sees as a format, and OpenAPI doesn't have a limitation on data formats. We could avoid these errors by ignoring whatever types that don't implement that trait, but that means we should set a default, but the problem with implementing a default for all known types is that we'll end up with conflicting implementations (like, when we implement a dependent trait for generic types such as Option<T> or Vec<T>), and we can only get so far with specialization.

The other choice would be to do something similar to serde (like #[serde(skip)]). I'll make a patch for both of these features. But yeah, those are the only two choices I see at the moment. Ideas welcome! :)

[wafflespeanut]

We now support NaiveDateTime (when datetime feature is enabled) and UUID (when uid feature is enabled). I'm moving the macro work to next release.

[FFdhorkin]

We now support NaiveDateTime (when datetime feature is enabled) and UUID (when uid feature is enabled). I'm moving the macro work to next release.

I believe I'm having the same issue as mstump, but the 'uid' feature doesn't seem to help.

I tried changing my dependencies to include paperclip = { git = "https://github.com/wafflespeanut/paperclip.git", features = ["actix", "uid"] }

But it still chokes on this when I try to build:

#[api_v2_schema]
#[derive(Deserialize, Serialize, Validate, Debug, Clone)]
pub struct SomeTypeOfResponse {
    pub id: Uuid,
    pub name: String
}

with:

error[E0599]: no function or associated item named raw_schema found for struct uuid::Uuid in the current scope --> api/src/totallyrealfilename.rs:37:1 | 37 | #[api_v2_schema] | ^^^^^^^^^^^^^^^^ function or associated item not found in uuid::Uuid | = note: the method raw_schema exists but the following trait bounds were not satisfied: &mut uuid::Uuid : paperclip_core::v2::schema::Apiv2Schema &uuid::Uuid : paperclip_core::v2::schema::Apiv2Schema uuid::Uuid : paperclip_core::v2::schema::Apiv2Schema )

[wafflespeanut]

@FFdhorkin I already have a test for Uuid and DateTime in tree. I just ran the tests in my system and it worked fine. So,

1. What version of nightly are you using? The one pinned in this repository is nightly-2020-01-08. If you're using a higher version, then I can certainly try to support it.
2. Can you check if the commit hash for paperclip in your Cargo.lock is the same as the latest commit in this repository?

[FFdhorkin]

@FFdhorkin I already have a test for Uuid and DateTime in tree. I just ran the tests in my system and it worked fine. So,

1. What version of nightly are you using? The one pinned in this repository is `nightly-2020-01-08`. If you're using a higher version, then I can certainly try to support it.

2. Can you check if the commit hash for paperclip in your `Cargo.lock` is the same as the latest commit in this repository?

I'm using the pinned one you mentioned, though I've also tried with the latest nightly just to see if it made a difference. (I also tried specifying 'foo' as a feature, and it gave an error, so it seems to recognize the 'uid' feature)

The commit hash for paperclip (and paperclip-actix, core, and macros) in Cargo.lock is 612e4f1ccaeebeebe935782dbba62e73193aa8bb, same as the latest commit in the repo.

Also tried doing cargo build -vv. Didn't see anything that looked super relevant (it did pass a --cfg 'feature="uid"' parameter to rustc, though)

Whatever is going on, I suspect my comment on #72 is the same cause. Should I open a new issue for this conversation? Anything else I can do to help identify what's going on? Thanks!

[wafflespeanut]

One last thing. Can you try setting up a new Rust project with actix-web and try compiling and running a simple example with uuid crate? The linked example returns me the appropriate spec when I curl GET /api/spec. So, I'm beginning to think that this is more of a package management problem than paperclip itself. It's possible that there's a version conflict somewhere - paperclip compiled with some version of uuid, whereas the one you use in your project is using some other version. What if you delete Cargo.lock file and rebuild your project?

P.S. Sorry for the late reply (I'm on vacation. :sweat_smile:).

[FFdhorkin]

I believe you were correct about it being a package management problem. It took a fair bit of effort massaging our dependencies to use only one version of uuid, but it appears to have made the particular issue I was talking about here go away. I still don't have paperclip running in our monorepo (it's panicking when I run), but it's compiling, at least. (I'll post in other issues about what I'm seeing now)