Added has_table_tuples to implement HasTable for n-uples

[LucaCappelletti94]

As per discussion #4870

[LucaCappelletti94]

Why doesn't Column implement HasTable?

[weiznich]

Columns likely don't implement HasTable because this trait is mostly applied to rust side "model" structs and not sql side zero sized types. If it's reasonably possible to add a impl<C> HasTable for C where T: Column it might be acceptable to add it. If it requires us generating this impl for each column that will likely increase the size of the schema.rs file, which should be avoided.

[LucaCappelletti94]

Columns likely don't implement HasTable because this trait is mostly applied to rust side "model" structs and not sql side zero sized types. If it's reasonably possible to add a impl<C> HasTable for C where T: Column it might be acceptable to add it. If it requires us generating this impl for each column that will likely increase the size of the schema.rs file, which should be avoided.

Will try to do as you suggest.

[LucaCappelletti94]

Since there is already the following blanket:

impl<T: HasTable> HasTable for &T {
    type Table = T::Table;

    fn table() -> Self::Table {
        T::table()
    }
}

The proposed blanket impl<C> HasTable for C where T: Column is not implementable as:

conflicting implementations of trait `HasTable` for type `&_`
downstream crates may implement trait `query_source::Column` for type `&_`

So we can either have a tuple where all entries have HasTable implementing HasTable, or a tuple where all entries implement Column having HasTable. I believe that the first option should be the preferable one, and then a user is always free to add a macro which generates the HasTable trait for all columns. I wonder whether there should be a feature or variant of the table! macro to enable such a thing in diesel.

[weiznich]

Sounds reasonable

[LucaCappelletti94]

@weiznich the PR should be ready, even though due to the inability to implement the HasTable trait for C: Column it falls rather short from its initial objective.

While I agree it would be disagreeable to extend by default the schema size by implementing HasTable for all columns, would it be acceptable to do so with an optional feature gate (e.g. "column-has-table")?

[LucaCappelletti94]

I tried to do the above, but it leads to a cascade of:

ambiguous associated type `Table` in bounds of `TypedColumn`
associated type `Table` could derive from `HasTable`
associated type `Table` could derive from `Column`