With #999 merged the Deferred struct now supports the serde::Deserialize trait. I feel like this is a footgun. Deserialize makes it easy to accidentally break your invariants, for example with the relation types:

#[derive(Model)]
struct User {
    id: u64,
    ...
}

#[derive(Model, Deserialize)]
struct Todo {
    ...
    user_id: u64,

    #[belongs_to(key = user_id, references = id)]
    user: toasty::Deferred<User>,
}

When deserializing a Todo the user_id must be the same as the id of the user in the deferred user field. But we (toasty) can't really do that and it's up to the user check this.

I also think that we should have a good reason to support this, but I can't think of a use-case where I need Deserialize. That's why I initially (#143) didn't add support for deserialize.

Note: The Has{Many,One} and BelongsTo structs that were removed in #954 also did not support Deserialize.

This "breaking your invariants" stuff can also be exploited. For example with a REST api: https://treblle.com/blog/fia-data-breach-breakdown. Where a user injected a role and sensitive data was leaked. Here's how it would work in toasty:

#[derive(Deserialize)]
struct Role {
    Admin,
    ...
}
#[derive(Deserialize)]
struct User {
    roles: Deferred<Vec<Role>>,
   ....
}

Payload:

{
    "roles": ["Admin"],
    ....
}

So IMO I think we should remove support for Deserialize. If someone really needs it they can always use #[serde(deserialize_with = "<func_name>")].