SeaQL/sea-orm · error

Failed to get double

Error message

Failed to get double

What it means

This panic comes from `.expect("Failed to get double")` in `ProxyRow`'s MySQL driver conversion. It fires when `sqlx::Row::try_get` cannot decode the column at `c.ordinal()` into `Option<f64>` for a column whose declared type string is "DOUBLE". Since the conversion is written with `expect`, any decode failure aborts the thread with this message. It indicates the stored value or column type is not actually a decodable DOUBLE.

Source

Thrown at sea-orm-sync/src/driver/sqlx_mysql.rs:425

                        "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())
                                    .expect("Failed to get string")
                                    .map(Box::new),
                            )
                        }

                        #[cfg(feature = "with-chrono")]

View on GitHub (pinned to e29bcd1b41)

Solutions

  1. Re-run `SHOW CREATE TABLE` and refresh the table metadata used by ProxyRow so the DOUBLE column is still DOUBLE.
  2. Check the column is DOUBLE and not DECIMAL/FLOAT/TEXT; correct schema or mapping accordingly.
  3. Ensure sqlx and its MySQL connector are up to date and consistent across the build.
  4. Replace the `expect` with error propagation if you control the driver code, to get a proper DbErr instead of a panic.

Example fix

// before
"DOUBLE" => {
    Value::Double(row.try_get(c.ordinal()).expect("Failed to get double"))
}
// after
"DOUBLE" => {
    Value::Double(row.try_get::<Option<f64>, _>(c.ordinal())
        .map_err(|e| DbErr::TryGetErr(...))? // propagate instead of panicking
        .unwrap_or_default())
}
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the column is a true DOUBLE before querying
let col = table_columns.iter().find(|c| c.name == "my_col").expect("column missing");
assert_eq!(col.type_name, "DOUBLE", "column type drift detected");

Try / catch

// The panic comes from .expect inside the driver; guard with catch_unwind at the boundary:
std::panic::catch_unwind(|| proxy_row_from(&row, &columns))
    .map_err(|_| DbErr::Custom("DOUBLE column decode failed".into()))?

Prevention

When it happens

Trigger: Reading a MySQL column whose metadata type is "DOUBLE" but whose raw value fails f64 decoding — typically after schema changes, or when the column is actually DECIMAL/TEXT and was mislabeled as DOUBLE in captured metadata.

Common situations: Column altered from DOUBLE to DECIMAL while cached metadata still says DOUBLE; MySQL connector version mismatches; querying generated columns whose reported type differs from returned value type.

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


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