Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upAllow renaming fields for #[insertable_into] #300
Comments
This comment has been minimized.
|
I think I'm going to rework the definition to allow pasting the struct def into the macro. We should test that all variants are handled.
|
This comment has been minimized.
|
This is what the "bottom" of the macro will probably look like for (
table_name = $table_name:ident,
struct_ty = $struct_ty:ty,
lifetimes = ($($lifetime:tt),*),
values_ty = $values_ty:ty,
self_to_columns = $self_to_columns:pat,
columns = ($($column_name:ident, $column_kind:ident),+),
) => { parse_as_item! {
impl<$($lifetime,)* 'insert, DB> ::diesel::persistable::Insertable<$table_name::table, DB>
for &'insert $struct_ty where
DB: ::diesel::backend::Backend,
$values_ty: ::diesel::persistable::InsertValues<DB>,
{
type Values = $values_ty;
fn values(self) -> Self::Values {
use ::diesel::expression::{AsExpression, Expression};
use ::diesel::persistable::ColumnInsertValue;
let $self_to_columns = *self;
($(
column_insert_expr!($table_name::$column_name, $column_name, $column_kind)
,)+)
}
}
}};Then it's just a matter of parsing all the various struct definitions into it. A messy and incomplete example for tuple structs: (
($table_name:ident)
$(pub)* struct $struct_name:ident <$($lifetime:tt),+> ($(
#[column_name($column_name:ident)]
pub $field_type:ty,
)+);
) => {
Insertable! {
table_name = $table_name,
struct_ty = $struct_name<$($lifetime),+>,
lifetimes = ($($lifetime),+),
values_ty = ($(
::diesel::persistable::ColumnInsertValue<
$table_name::$column_name,
::diesel::expression::bound::Bound<
<$table_name::$column_name as ::diesel::expression::Expression>::SqlType,
&'insert $field_type,
>,
>
,)+),
self_to_columns = $struct_name($(ref $column_name),+),
columns = ($($column_name, regular),+),
}
};Going to scrap most of the code from the stream this morning, as we need to fundamentally approach the macro differently, since the expression needs to focus on pattern matching not on field access. And I need to approach it from a parsing point of view as well. Will swing at this a bit more during tomorrows stream unless someone else wants to take over it. |
This comment has been minimized.
|
This is addressed by #303 |
sgrif commentedApr 23, 2016
The column name should be able to differ from the field name. We already do this for tuple structs. We need to do this for named fields as well. I believe this already works, but we don't have an explicit test case for it. We need to make sure it's tested. I'm noting this as I'm reworking the entirety of how the derivation works, and we need to make sure this case is handled.