Entity format

[tyt2y3]

#105

[tqwewe]

Looking awesome!

We don't want to use the shorter #[sea(...)] instead of #[sea_orm(...)]?

Also, if we wanted this to be more correct (something I even forgot to do), we should add :: before the types. For example impl ::std::default::Default ... and impl ::sea_orm::..., but it's not super important.

Do you think it's worth updating all the macros to take in an DeriveInput parameter and return syn::Result<TokenStream>, and use the struct to store the data?
Now it has a few inconsistencies, and updating it like that would allow a macro_rules for simplifying the lib.rs file.
Eg:

macro_rules! create_derive {
    ($name:ident $(, $( $attrs:ident ),+)?) => {
        paste! {
            #[proc_macro_derive($name, attributes($( $( $attrs ),*)?))]
            pub fn [< $name:snake >](input: TokenStream) -> TokenStream {
                let input = parse_macro_input!(input as DeriveInput);
                derives::[<expand_ $name:snake>](input)
                    .unwrap_or_else(Error::into_compile_error)
                    .into()
            }
        }
    }
}

create_derive!(DeriveEntity, sea);
create_derive!(DerivePrimaryKey);
create_derive!(DeriveColumn);
create_derive!(DeriveCustomColumn);
create_derive!(DeriveModel, sea);
create_derive!(DeriveModelColumn, sea);
create_derive!(DeriveModelPrimaryKey, sea);
create_derive!(DeriveActiveModel);
create_derive!(DeriveActiveModelBehavior);
create_derive!(DeriveRelation, sea);
create_derive!(FromQueryResult);

(the macro above works with the paste crate)

[tyt2y3]

We don't want to use the shorter #[sea(...)] instead of #[sea_orm(...)]?

I guess the norm is to use the crate's name itself?

Also, if we wanted this to be more correct (something I even forgot to do), we should add :: before the types. For example impl ::std::default::Default ... and impl ::sea_orm::..., but it's not super important.

I think it's fine if someone wants to alias something else as sea_orm.

Do you think it's worth updating all the macros to take in an DeriveInput parameter and return syn::Result<TokenStream>, and use the struct to store the data?

Now it has a few inconsistencies, and updating it like that would allow a macro_rules for simplifying the lib.rs file.

Yes I do think it's a good idea.

[tqwewe]

I guess the norm is to use the crate's name itself?

I think it's fine having a shorter version, nothing will conflict with sea. For example, the async-graphql crate uses #[graphql(...)], instead of the full async-graphql.

I think it's fine if someone wants to alias something else as sea_orm.

Sure, it's a very small thing. But I think it's usually a standard thing when writing macros, mainly for ::std::... std library types.

[tyt2y3]

I hope sea_orm is not too long to be obstructive )
I do agree on the ::std thing, but we actually use create as sea_orm ourselves

sea-orm/src/tests_cfg/fruit.rs

Line 1 in a186338

use crate as sea_orm;