Proposal: ForeignKey marker trait for Diesel schemas

[LucaCappelletti94]

Backend

PostgreSQL, MySQL, SQLite, Others

What do you want to add to diesel?

I propose a new marker trait for foreign keys in Diesel, providing compile-time type safety based on the SQL type of the columns.

In my code base, I use these markers to define higher-level semantics and control which getter/setter methods are allowed based on foreign key relationships.

Implementation notes

use diesel::sql_types::*;
use diesel::Column;

/// Defines a trait for determining whether two SQL types are compatible
/// for a foreign key relationship in Diesel.
pub trait ForeignKeyCompatibleType<Other> {}

impl<T> ForeignKeyCompatibleType<T> for T {}
impl<T> ForeignKeyCompatibleType<Nullable<T>> for T {}
impl<T> ForeignKeyCompatibleType<T> for Nullable<T> {}

/// Defines a trait for determining whether two columns are compatible
/// for a foreign key relationship in Diesel.
pub trait ForeignKeyCompatibleColumn<Other>
{
}

impl<C1, C2> ForeignKeyCompatibleColumn<C2> for C1
where
    C1: Column,
    C2: Column,
    C1::SqlType: ForeignKeyCompatibleType<C2::SqlType>,
{
}

/// Marker trait for foreign key relationships between tuples of columns.
pub trait CompatibleForeignKeyColumns<Other> {}

/// Single-column tuple
impl<C1, C2> CompatibleForeignKeyColumns<(C1,)> for (C2,)
where
    C2: ForeignKeyCompatibleColumn<C1>,
{
}

/// Two-column tuple
impl<C1, C2, C3, C4> CompatibleForeignKeyColumns<(C1, C2)> for (C3, C4)
where
    C3: ForeignKeyCompatibleColumn<C1>,
    C4: ForeignKeyCompatibleColumn<C2>,
{
}

/// Three-column tuple
impl<C1, C2, C3, C4, C5, C6> CompatibleForeignKeyColumns<(C1, C2, C3)> for (C4, C5, C6)
where
    C4: ForeignKeyCompatibleColumn<C1>,
    C5: ForeignKeyCompatibleColumn<C2>,
    C6: ForeignKeyCompatibleColumn<C3>,
{
}

/// Marker trait for foreign key relationships between tables
pub trait ForeignKey<HostColumns, ReferencedColumns>
where
    HostColumns: CompatibleForeignKeyColumns<ReferencedColumns>,
{
}

Note: Implementations for the tuples should be generated automatically using Diesel’s macro approach, such as:
diesel_derives::__diesel_for_each_tuple!(has_table_tuples);

Additional details

• Stricter than most databases: e.g., INT → BIGINT references fail at compile time, while it is fine in many DBs.
• No implicit type coercion allowed.
• Must be written by hand currently, though in my codebase I rely on a simple codegen tool to generate them automatically.

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

[LucaCappelletti94]

I think that after a first draft of the trait is fully defined, several helper methods could be added on top of it, analogously to what is currently possible with the BelongsTo trait.