A column changed type 8 days after I mapped it, and nothing told me

I was rewriting a Java/Spring backend to Go. The database wasn't going anywhere — it
already existed, with real data in it, and eighteen tables' worth of history behind it.
The plan was simple: keep the schema, replace the service layer.

Early on, asset looked like this:

CREATE TABLE `asset` (
    `id`    bigint       NOT NULL AUTO_INCREMENT,
    ...
    `value` int          NOT NULL,
    PRIMARY KEY (`id`)
);

I mapped it to a Go struct by hand, the way you do when you're moving fast and the table
is right there on the screen:

type Asset struct {
    ID    int64
    Value int64
    ...
}

Eight days later, a migration I wasn't looking at changed it:

ALTER TABLE `asset`
    CHANGE `value` `value` DECIMAL(19, 2) NULL DEFAULT NULL;

int NOT NULL became decimal(19,2) NULL. Two changes at once, and my hand-written
struct still said int64, no pointer, no way to represent NULL. Nothing failed loudly —
GORM will happily scan a decimal into an int64 and either round it or blow up on a NULL,
depending on the day. It's the kind of bug that shows up as "why is this value off by a
few cents" three weeks later, not as a compile error.

That's when it clicked: I don't need a unit test for "does my Go struct still match the
asset table." I need something that reads the table and tells me if it doesn't.

So instead of writing the struct by hand, I pointed a small code generator I'd built for
exactly this — reads live schema over JDBC, spits out Go structs — at the same database,
and diffed the output against what I had. It caught value immediately: wrong type,
wrong nullability, no compile error to warn me.

None of this is exotic. If you're doing DB-first Go with GORM, this is just what happens
when the schema evolves and your structs are maintained by hand, by a human, on a Tuesday.
The fix isn't "write more tests" — it's "stop hand-maintaining the mapping between a table
and a struct, and regenerate it from the table instead." A unit test only catches what you
thought to test. A schema read catches what actually changed.

I ended up formalizing this into SQL DAL Maker
— it reads live JDBC metadata and generates the DAO/model layer for Go (and a few other
languages) from it, so the struct-vs-schema gap can't quietly reopen every time someone
runs a migration. But the generator isn't really the point of this post. The point is:
if your models are hand-typed and your schema isn't frozen, you already have this bug
somewhere. You just haven't hit it yet.