seaorm-cli codegen maps col(big_unsigned(..)) to i64

[CallMeMSL]

Description

table clolumns with big_unsigned type get mapped to an i64 field during entity generation by seaorm-cli

Steps to Reproduce

1. create a Table in a migration up with a BigUnsigned column

#[async_trait::async_trait]
impl MigrationTrait for Migration {
    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        manager
            .create_table(
                Table::create()
                    .table(User::Table)
                    .if_not_exists()
                    .col(pk_auto(User::Id))
                    .col(big_unsigned(User::DiscordId))
                    .to_owned(),
            )
            .await
    }

    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        manager
            .drop_table(Table::drop().table(User::Table).to_owned())
            .await
    }
}

#[derive(DeriveIden)]
enum User {
    Table,
    Id,
    DiscordId,
}

2. run sea-orm-cli generate entity -o entity/src -l

generated user.rs:

//! `SeaORM` Entity, @generated by sea-orm-codegen 1.1.4

use sea_orm::entity::prelude::*;
use serde::{Deserialize, Serialize};

#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Eq, Serialize, Deserialize)]
#[sea_orm(table_name = "user")]
pub struct Model {
    #[sea_orm(primary_key)]
    pub id: i32,
    pub discord_id: i64,
}

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

impl ActiveModelBehavior for ActiveModel {}

Expected Behavior

pub discord_id: u64 in generated entity

Actual Behavior

pub discord_id: i64 in generated entity

Reproduces How Often

every time

Workarounds

Reproducible Example

see above

Versions

1.1.4

[rob0rt]

I just ran into this myself. In my application I'm using Postgres, which doesn't support unsigned integers, so the created column by the migration is just a regular [signed] bigint. Since the entity generation is based off the live schema, that means that the knowledge of it being "unsigned" gets lots.

You can see if the same is happening for you by looking at the types of the columns of your database after applying the migration. If it's just BIGINT, that would explain it IIUC.

IMO, if what I described above is true, I would expect the migration to either fail with an error (unsupported data type for DB) or otherwise indicate as such.