Best practice for deriving/implementing ToSql, FromSql, Queryable

[vdods]

Hi there, I've been getting great usage out of Diesel's ORM, but I've been having troubling finding a good and ergonomic way to implement these various traits for my custom types. I've searched around quite a bit, but I haven't been able to find a best practices document describing this pretty central workflow.

Here's an example of what my code looks like.

Here's the data type I want to use in the ORM. For reference, I'm supporting the SQLite backend.

use chrono::{DateTime, NaiveDateTime, Utc};

/// This newtype is meant to store a DateTime<Utc> using a specific Precision, i.e.
/// Secs, Millis, Micros, Nanos.
#[derive(diesel::AsExpression, Clone, Copy, Debug, Eq, Ord, PartialEq, PartialOrd)]
#[diesel(deserialize_as = "NaiveDateTime")]
#[diesel(serialize_as = "NaiveDateTime")]
#[sql_type = "diesel::sql_types::Timestamp"]
pub struct DateTimeUtc<P: Precision> {
    dtu: DateTime<Utc>,
    m: std::marker::PhantomData<P>
}

Don't worry about the semantics of the specific data type here, there are many other data types to which this question applies, and my question is about the derivation/implementation of the diesel traits themselves.

And of course the from/into implementations:

impl<P: Precision> std::convert::From<DateTime<Utc>> for DateTimeUtc<P> {
    fn from(date_time: DateTime<Utc>) -> Self {
        // Self::from TimePair is what does the truncation.
        Self::from(TimePair::from(date_time))
    }
}

impl<P: Precision> std::convert::Into<DateTime<Utc>> for DateTimeUtc<P> {
    fn into(self) -> DateTime<Utc> {
        self.dtu
    }
}

impl<P: Precision> std::convert::Into<DateTime<Utc>> for &DateTimeUtc<P> {
    fn into(self) -> DateTime<Utc> {
        self.dtu
    }
}

And finally, here are my trait implementations:

impl<P> diesel::serialize::ToSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite> for DateTimeUtc<P>
where
    NaiveDateTime: diesel::serialize::ToSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite>,
    P: Precision,
{
    fn to_sql<W: std::io::Write>(
        &self,
        out: &mut diesel::serialize::Output<W, diesel::sqlite::Sqlite>,
    ) -> diesel::serialize::Result {
        <NaiveDateTime as diesel::serialize::ToSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite>>::to_sql(
            &self.into(),
            out,
        )
    }
}

impl<P> diesel::deserialize::FromSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite> for DateTimeUtc<P>
where
    NaiveDateTime: diesel::deserialize::FromSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite>,
    P: Precision,
{
    fn from_sql(bytes: Option<&<diesel::sqlite::Sqlite as diesel::backend::Backend>::RawValue>) -> diesel::deserialize::Result<Self> {
        Ok(DateTimeUtc::from(<NaiveDateTime as diesel::deserialize::FromSql<diesel::sql_types::Timestamp, diesel::sqlite::Sqlite>>::from_sql(bytes)?))
    }
}

impl<ST, P> diesel::Queryable<ST, diesel::sqlite::Sqlite> for DateTimeUtc<P>
where
    NaiveDateTime: diesel::Queryable<ST, diesel::sqlite::Sqlite>,
    P: Precision,
{
    type Row = <NaiveDateTime as diesel::Queryable<ST, diesel::sqlite::Sqlite>>::Row;
    fn build(row: Self::Row) -> Self {
        DateTimeUtc::from(NaiveDateTime::build(row))
    }
}

These implementations are all boilerplate that theoretically should be automatically derivable, but my attempts to do so using #[diesel(deserialize_as = "NaiveDateTime")] and #[diesel(serialize_as = "NaiveDateTime")] attributes don't seem to be sufficient (but they are necessary).

I believe I've tried various derive macros for my data types but haven't found the one that clicks into place and makes this as trivial as it seems like it should be. In particular, it seems like if there are From/Into implementations into a type that Diesel knows how to handle, then deriving the traits should be as trivial as specifying deserialize_as and serialize_as.

Can anyone show me where I'm going wrong?

A best-practices guide for implementing the Diesel ORM traits would be a great and much sought-after addition to http://diesel.rs/guides/

Thanks!

[weiznich]

This won't be a complete answer, just pointing out a few things:

#[diesel(serialize_as = "NaiveDateTime")]

This attribute isn't available at any released diesel version yet, so maybe just don't expect a full guide to be written for unreleased stuff. You should likely also state very clearly as part of your question which diesel master revision you are using. Otherwise it may be hard to answer some points in detail.

#[diesel(deserialize_as = "NaiveDateTime")]
#[diesel(serialize_as = "NaiveDateTime")]

Both deserialize_as and serialize_as don't work with the AsExpression derive. #[diesel(deserialize_as=…)] exists for #[derive(Queryable)], #[diesel(serialize_as = …)] exists for #[derive(Insertable)]. See the corresponding documentation there for the exact usage. I feel that the usage there is much more in line with the behaviour you are looking for. You current example is more tailored around implementing support for a fully custom type.

impl<ST, P> diesel::Queryable<ST, diesel::sqlite::Sqlite> for DateTimeUtc<P>

This can be derived by deriving #[derive(FromSqlRow)]

I believe I've tried various derive macros for my data types but haven't found the one that clicks into place and makes this as trivial as it seems like it should be. In particular, it seems like if there are From/Into implementations into a type that Diesel knows how to handle, then deriving the traits should be as trivial as specifying deserialize_as and serialize_as.

Putting everything behind one derive is just not an option as there are a lot of cases where only a subset of the conversions offered by the different derives are valid or even possible. Therefore the split into different derives. That written: Diesel there tries to offer a basic interface that allows all possible usages, not the most ergonomic interface. If you want you can implement a more opinionated take on this as third party derive.

A best-practices guide for implementing the Diesel ORM traits would be a great and much sought-after addition to http://diesel.rs/guides/

Contributions to the guides are always welcome. Feel free to submit a PR if you feel that something is missing.