Compact Entity format

[nappa85]

I was trying your crate, seems promising, but the way you choose to represent models is too verbose.
For example I've a DB table with 53 fields, using your system I've written like 210 LOC, repeating the same informations like 3 times.

I think everything could be done with a single proc_macro, that takes a standard Rust struct and replaces it with a module with the same name of the struct, with Model struct with more or less the same contents of the original struct, Column enum with structs fields as variants, automatic impl ColumnTrait for Column with a type mapping, where the mapping fails you can use a field notation to override it (comes handy for custom types), table name and primary key can be specified with a struct notation, what's missing?
Relations, well, this have to be specified externally, but you can point the enum with another notation, and if the notation isn't present you generate a void enum.

After that, if I can add something more, I often use Cow on my entities, because this way I'm not forced to clone Strings when updating/creating. With your system I can't, because Model doesn't support a lifetime. It's not a big problem, but it blocks also other custom types with a lifetime

[tqwewe]

I haven't thought of this before, but I think I can agree with you somewhat.

For example, Entity, Model, Column, PrimaryKey, PrimaryKeyTrait & ColumnTrait could be combined into a single struct definition with derives or a single SeaORM derive.
From:

#[derive(Copy, Clone, Default, Debug, DeriveEntity)]
pub struct Entity;

impl EntityName for Entity {
    fn schema_name(&self) -> Option<&str> {
        Some("public")
    }

    fn table_name(&self) -> &str {
        "users"
    }
}

#[derive(Clone, Debug, PartialEq, DeriveModel, DeriveActiveModel)]
pub struct Model {
    pub id: Uuid,
    pub created_at: DateTimeWithTimeZone,
    pub updated_at: DateTimeWithTimeZone,
    pub username: String,
    pub password: String,
    pub email: Option<String>,
}

#[derive(Copy, Clone, Debug, EnumIter, DeriveColumn)]
pub enum Column {
    Id,
    CreatedAt,
    UpdatedAt,
    Username,
    Password,
    Email,
}


#[derive(Copy, std::clone::Clone, std::fmt::Debug, EnumIter, DerivePrimaryKey)]
pub enum PrimaryKey {
    Id,
}

impl PrimaryKeyTrait for PrimaryKey {
    fn auto_increment() -> bool {
        false
    }
}

#[derive(Copy, Clone, Debug, EnumIter)]
pub enum Relation {}

impl ColumnTrait for Column {
    type EntityName = Entity;
    fn def(&self) -> ColumnDef {
        match self {
            Self::Id => ColumnType::Uuid.def(),
            Self::CreatedAt => ColumnType::Timestamp.def(),
            Self::UpdatedAt => ColumnType::Timestamp.def(),
            Self::Username => ColumnType::String(None).def(),
            Self::Password => ColumnType::String(None).def(),
            Self::Email => ColumnType::String(None).def().null(),
        }
    }
}

Into:

#[derive(Clone, Debug, PartialEq, SeaORM)]
#[schema_name = "public"]
#[table_name = "coupons"]
pub struct Model {
    #[primary_key]
    #[auto_increment = false]
    pub id: Uuid,
    pub created_at: DateTimeWithTimeZone,
    pub updated_at: DateTimeWithTimeZone,
    pub username: String,
    pub password: String,
    pub email: Option<String>,
}

I think this wouldn't be too hard as a lot of information could be inferred from the struct.
For example:

• If a field is an Option<T>, then .null() would be added in the ColumnTrait
• The Column enum could be generated from the model's fields

Obviously with this comes a lack of customizability. But this could be solved by allowing manual implementations where needed perhaps?

[tyt2y3]

Thank you for your interest. I will first talk about the original ideas and choices, and may add more thoughts on later post.

The first thing is, I do not want to invent any DSL or a custom syntax or semantics. It will definitely be much less verbose, but it will be hard to understand and reason about, and people don't want to learn a new micro-language. Sooner or later, someone will have a need to customise the behaviour and hack the thing, and it will be much easier to do so in the plain Rust language.

(Just a small use case, how can I dynamically remap the table name based on environment variables?)

If there are tricks to reduce the verbosity of the Entity file without countering the above, I'll definitely adopt.

A lesser motivation would be code completion. List out the essential symbols and traits will be helpful.

But after all it is about how much information we want to present on plain sight. Too much it is hard to digest, too little it will be hard to see-through.

[nappa85]

Yes, I understand your point of view, and it was exactly the reply I thought for the question "why didn't they already made this?".
But, as @acidic9 pointed, there can be default impl via derive macro and custom impl in plain Rust without any problems.
As far as I can see, code completion works with macro-produced code without problems.
Macros aren't made to replace code, but to easy the life of who writes it.

For example, serde has a derive macro for Serialize and Deserialize, but anyone can manually derive the traits for non-standard situations, and there are lots of docs about it.

I would prefer a serde-like approach, where the default is easily reached with a macro, and non-default-fitting situations can be covered in plain Rust.

[tyt2y3]

I also think that having to use both CamelCase and snake_case when referring to attributes is slightly awkward.

Is it better or worse if we break the Rust convention and use snake_case enums?

[tqwewe]

I don't think so honestly, I think keeping the enum as CamelCase... and just renaming it through the derive macro. And the derive macro would just generate an implementation of std::string::ToString

[tyt2y3]

Serde is a brilliant library and there is definitely a lot to learn and borrow from.

Yes I would prefer to have a more compact form, as long as it is compatible with the longer form.

And that the derive macro should not do too much magic other than providing syntax sugars.

[tyt2y3]

Also, it'd be better if we settle on a 'base format' first, and versions afterwards to be backward compatible.
That way, we can incrementally release enhancements towards the 'short format', while the codegen can maintain the capability to generate both formats.

[tyt2y3]

@acidic9 the format you propose already looks good. Perhaps we just need to think about the relations.

[nappa85]

I've put together a minimal impl, have a look https://github.com/nappa85/sea-orm-macro/
Inside tests there is a working example.
Sure there is space for improvement, but it can be a starting point

[tyt2y3]

I've put together a minimal impl, have a look https://github.com/nappa85/sea-orm-macro/
Inside tests there is a working example.
Sure there is space for improvement, but it can be a starting point

Wow thank you for the quick update. Looks great so far. I was just thinking how to name it (lol) perhaps, AutoEntity, EntityDef, or simply Entity?

[nappa85]

Wow thank you for the quick update. Looks great so far. I was just thinking how to name it (lol) perhaps, AutoEntity, EntityDef, or simply Entity?

I've named it AutoColumn because it's main purpose is to generate Column from Model, but it generates optionally also Entity and PrimaryKey, so maybe a more generic AutoDef?

[tyt2y3]

Yeah AutoDef sounds good too.

[tqwewe]

I feel like AutoDef is a little ambiguous. For example, serde just has Serialize and Deserialize. I like the sound of Schema or Entity or Table

[tyt2y3]

Well, Entity is the most almighty I guess.