Porting eq_null trait to diesel 2.0.0

[ensc]

I have a trait which generates (<v.is_none()> AND <column> IS NULL) OR (<v.is_some()> AND <column> = <v>) sql.

A reduced variant

#[macro_use] extern crate diesel as _;

use diesel::dsl::{And, Eq, AsExprOf};
use diesel::sql_types::{ Bool };

use diesel::*;

diesel::table! {
    foo (id) {
	id -> Int4,
	data -> Nullable<Int4>,
    }
}

pub trait EqNull
where
    Self: diesel::expression_methods::ExpressionMethods + Clone,
    // Self::SqlType: SqlType,          // trivial 2.0.0 change
{
    fn eq_null<T>(self, v: Option<T>) ->
	And<AsExprOf<bool, Bool>, Eq<Self, AsExprOf<Option<T>, Self::SqlType>>>
    where
	Option<T>: diesel::expression::AsExpression<Self::SqlType>,
    {
	// reduced example; full implementation contains another 'v.is_none().and(self.is_null())' OR branch
	v.is_some().into_sql::<Bool>().and(self.eq(v))
    }
}

impl EqNull for foo::columns::data {}

fn _foo()
{
    foo::data.eq_null(Some(23));
}

fn main()
{
}

compiles with 1.4.6 but with 2.0.0 I am lost in a jungle of Nullable related additional trait bounds.

How can I express this with diesel 2.0.0? Does diesel 2 perhaps already contain another solution for the underlying problem (comparing with NULL)?

[weiznich]

This is now your forth question about how to port an application specific pattern to a unreleased diesel version. Please keep in mind that we generally do not provide any support for unreleased versions. We are happy to receive feedback about unreleased features, but it is generally expected that the documentation and related stuff is not comparable with a finished release yet.
Additionally your previous questions and your github profile indicate that your examples are coming from a commercially used code base. While it's totally fine to use diesel in such contexts, please understand that this forum is not the right place to ask for extensive support for free for this use case. I'm happy to provide some consulting on paid basis for those use cases.

[ensc]

This is now your forth question about how to port an application specific pattern to a unreleased diesel version. Please keep in mind that we generally do not provide any support for unreleased versions

sorry; with your posting #2696 I was under the impression that 2.0.0 is not far away and core features are stable. Due to troubles with a left_join I decided to give this version a try (and yes, it allows me to use the left_join). I thought, asking questions about porting things would

• give other people with similar problems an idea how to solve them
• help to improve diesel resp. its documentation

your examples are coming from a commercially used code

The application evolved from some rust-learning project of mine and will be placed under GPLv3 (adding a COPYING file on unfinished code does not have such a high priority for me).

[weiznich]

sorry; with your posting #2696 I was under the impression that 2.0.0 is not far away and core features are stable.

Most things are stable now, but we want to do a few more breaking changes before releasing 2.0 (see #2762 for example).

give other people with similar problems an idea how to solve them
help to improve diesel resp. its documentation

Any help to improve the documentation is welcome, but I would like to keep documentation about unfinished features/releases in tree and not somewhere else, as such things tend to get outdated quite quickly.

The application evolved from some rust-learning project of mine and will be placed under GPLv3 (adding a COPYING file on unfinished code does not have such a high priority for me).

Adding the corresponding license file will prevent such things in the future. It's just that I generally prefer not do other peoples work for free. Having at least access to the corresponding code under some open source license definitively helps there. I'm not implying that this was your intention, that's just a general point.

[ensc]

fwiw, trick was to constrain the associated IsNull type and the final solution is

pub trait EqNull
where
    Self: diesel::expression_methods::ExpressionMethods + Clone,
    Self::SqlType: diesel::sql_types::SqlType<IsNull = is_nullable::IsNullable>,
{
    #[allow(clippy::type_complexity)]
    fn eq_null<U>(self, v: Option<U>) ->
	Or<And<BoolBound, IsNull<Self>>,
	   And<BoolBound, Eq<Self, AsExprOf<Option<U>, Self::SqlType>>, Nullable<Bool>>,
	   Nullable<Bool>>
    where
	Option<U>: diesel::expression::AsExpression<Self::SqlType>,
    {
	use diesel::{ IntoSql, BoolExpressionMethods };

	let fn_bool = |v: bool| v.into_sql::<Bool>();

	fn_bool(v.is_none()).and(self.clone().is_null())
	    .or(fn_bool(v.is_some()).and(self.eq(v)))
    }
}

[weiznich]

Another possibility (depending on the database backend you are using), is to use either the IS DISTINCT FROM operator (postgres specific) or the IS operator (sqlite specific)

[ensc]

thanks; I was not aware about the sqlite operator yet.

IS DISTINCT FROM is already used in the postgres related implementation.