SeaQL/sea-orm · error

Failed to get big integer

Error message

Failed to get big integer

What it means

In `ProxyRow`, MySQL `MEDIUMINT` and `BIGINT` columns are fetched as `i64` via `row.try_get` and unwrapped with `.expect("Failed to get big integer")`. If sqlx cannot decode the value as i64 (NULL, or a value type inconsistent with the described metadata), the expect panics with this message.

Source

Thrown at src/driver/sqlx_mysql.rs:427

                                .expect("Failed to get unsigned integer"),
                        ),
                        "MEDIUMINT UNSIGNED" | "BIGINT UNSIGNED" => Value::BigUnsigned(
                            row.try_get(c.ordinal())
                                .expect("Failed to get unsigned big integer"),
                        ),
                        "TINYINT" => Value::TinyInt(
                            row.try_get(c.ordinal())
                                .expect("Failed to get tiny integer"),
                        ),
                        "SMALLINT" => Value::SmallInt(
                            row.try_get(c.ordinal())
                                .expect("Failed to get small integer"),
                        ),
                        "INT" => {
                            Value::Int(row.try_get(c.ordinal()).expect("Failed to get integer"))
                        }
                        "MEDIUMINT" | "BIGINT" => Value::BigInt(
                            row.try_get(c.ordinal()).expect("Failed to get big integer"),
                        ),
                        "FLOAT" => {
                            Value::Float(row.try_get(c.ordinal()).expect("Failed to get float"))
                        }
                        "DOUBLE" => {
                            Value::Double(row.try_get(c.ordinal()).expect("Failed to get double"))
                        }

                        "BIT" | "BINARY" | "VARBINARY" | "TINYBLOB" | "BLOB" | "MEDIUMBLOB"
                        | "LONGBLOB" => Value::Bytes(
                            row.try_get::<Option<Vec<u8>>, _>(c.ordinal())
                                .expect("Failed to get bytes")
                                .map(Box::new),
                        ),

                        "CHAR" | "VARCHAR" | "TINYTEXT" | "TEXT" | "MEDIUMTEXT" | "LONGTEXT" => {
                            Value::String(
                                row.try_get::<Option<String>, _>(c.ordinal())

View on GitHub (pinned to e29bcd1b41)

Solutions

1. Change the entity field to `Option<i64>` or enforce NOT NULL on the column
2. Regenerate entities after migrations to eliminate type/nullability drift
3. Correct mock/proxy handlers to supply `i64` values for BIGINT/MEDIUMINT columns
4. Inspect the SELECT list for expressions that change type or nullability

Example fix

// before
pub total: i64,
// after
pub total: Option<i64>,

// Verify MEDIUMINT/BIGINT columns before decoding
SELECT COLUMN_TYPE, IS_NULLABLE FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ? AND COLUMN_NAME = ?;

fn is_i64_compatible(col_type: &str, nullable: bool, value_is_null: bool) -> bool {
    matches!(col_type.to_ascii_lowercase().as_str(), "bigint" | "mediumint")
        && !nullable && !value_is_null
}

When it happens

Trigger: A MEDIUMINT/BIGINT column containing NULL, or a value whose real type differs from the described metadata (e.g. BIGINT UNSIGNED handled by a different arm, or mocked value), decoded through the proxy driver.

Common situations: NULL bigint from aggregate subqueries or LEFT JOINs; schema drift where BIGINT became nullable; proxy-driver mocks returning f64 or string for BIGINT columns.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

• Failed to get unsigned integer
• Failed to get unsigned big integer
• Failed to get tiny integer
• Failed to get small integer
• Failed to get integer

AI-assisted analysis of SeaQL/sea-orm@e29bcd1b41 (2026-09-10). Data as JSON: /api/errors/a37df81100798ab4. Report an issue: GitHub.