Using deserialize_as on Nullable/Option values.

[RedIODev]

I use deserialize_as to deserialize a blob from sqlite as an Uuid from the uuid library. The code for the Uuid wrapper allowing deserialization can be found in this issue. It works great with non nullable Uuids. But in case of nullable blobs in the sql database deserialize_as doesn't work for some reason. I tried multiple possible syntax that could be used and concluded on the following one causing the smallest error.
In this example UUID is the wrapper as linked above and Uuid is the target.

#[derive(Debug, Queryable, Selectable)]
#[diesel(table_name = xyz]
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
pub struct Example {
    #[diesel(deserialize_as = UUID)
    id: Uuid,    //works as Intended
    #[diesel(deserialize_as = Option<UUID>)
    opt_id: Option<Uuid>,   // doesn't work:
        // the trait bound `std::option::Option<Uuid>: TryFrom<std::option::Option<UUID>>` is not satisfied
    #[diesel(deserialize_as = Option<UUID>)
    opt_id2: Option<UUID> // works for some reason (probably identical to opt_id3)
    opt_id3: Option<UUID> // works obviously because UUID implements FromSql etc.
}

I really dislike the wrapper member in the struct. Is there a way to keep the unwrapped form in the struct?

[weiznich]

This is expected behavior. #[diesel(deserialize_as)] expects that this TryFrom impl exists as documented here.

Rust's standard library doesn't provide any neither of these impls:

• impl<F, T> TryFrom<Option<F>> for Option<T>
• impl<F, T> From<Option<F>> for Option<T> (Implied via the existing impl<T, U: Into<T>> TryFrom]<U> for T)

as far as I know that's a because the coherence checker sees that the existing impl<T> From<T> for T would overlap with one of these missing impls for T == F.

So long story short: You cannot use the same type for both the non-optional and optional field, you need to use another new type wrapper for the optional variant.

[RedIODev]

This at least makes things clear. Thank you.
Unfortunately this news is pretty annoying as it means twice the already large boilerplate to make a wrapper. I will try to create some macro magic to simplify this. Would this macro be interesting for diesel? If so I would love to share it with the project.

[weiznich]

Such a macro needs to make a rather large set of assumptions and therefore doesn't belong into diesel itself in my opinion. It shouldn't be too hard to provide it as third party crate if you believe that is useful for others.

[RedIODev]

If anyone reads this thread and has the same problem and wonders about the macro. I created a first version of said macro and uploaded it as "diesel_as_wrap" to crates.io.
The syntax I choose might be a bit unconventional but is explained in the macro doc.