fix: don't report a boolean default TRUE/1 as a schema difference (#3738)

[Yusufihsangorgel]

A boolean column with a default value fails SchemaVerifier.migrateAndValidate, even though the schema is semantically identical:

Not equal: `NOT NULL DEFAULT TRUE CHECK (is_first_login IN (0, 1))` (expected)
       and `NOT NULL DEFAULT (1) CHECK ("is_first_login" IN (0, 1))` (actual)

Booleans are stored as integers in SQLite, so a DEFAULT TRUE emitted by one schema snapshot and a DEFAULT 1 emitted by another describe the same column. But find_differences compared the default expressions textually and flagged a spurious difference, which breaks migration tests for any table with a boolean default (#3738).

Fix

When comparing column constraints, a boolean default written as TRUE/FALSE is now treated as equal to the same value written in its integer form 1/0. Genuinely different defaults are still reported as differences.

Tests

Added cases to find_differences_test.dart: a boolean default written as an integer, the exact #3738 scenario (boolean default + IN (0, 1) check), and a guard that a genuinely different default is still detected as a change. Reverting the fix makes the first two fail; with the fix the whole find_differences suite passes.

Closes #3738.

[simolus3]

Thanks! I'm still not entirely sure why we'd sometimes generate it as a boolean literal or a expression, but I agree it makes sense to treat TRUE and 1 as equal for default constraints.

There's a second schema verifier implementation for an upcoming drift release in future/drift_sqlite/lib/src/schema_verifier/find_differences.dart, could you please apply the changes there as well?

[simolus3]

These are rarely used, but constraints can also have a name attached to them and we should check that those are equal.

[Yusufihsangorgel]

Good catch. The TRUE/1 tolerance now only applies when both Default constraints have the same name; when the names differ it falls through to enforceEqual, which already asserts name equality in visitColumnConstraint, so a differently-named (or named-vs-unnamed) default is still reported. Added a regression test — with a boolean default under a different constraint name — covering equal default values under different CONSTRAINT names.

[Yusufihsangorgel]

Thanks for the quick review! Pushed an update:

• Constraint name equality is now checked before applying the TRUE/1 tolerance (details in the inline thread), plus a regression test for it.
• Applied the same change to the second verifier at future/drift_sqlite/lib/src/schema_verifier/find_differences.dart.

On why both forms show up: from what I've seen it's a cross-version rendering difference rather than one version emitting both — the reference schema (a serialized snapshot) renders the boolean default as TRUE, while the current generator emits DEFAULT (1), so it surfaces in the SchemaVerifier.migrateAndValidate path that compares a stored snapshot against freshly generated SQL. I chose to tolerate it in the verifier rather than normalize the rendering, since absorbing that kind of cross-version cosmetic difference is what the verifier is for — but happy to change the approach if you'd rather unify it at the generation side.

[simolus3]

Thanks!

[simolus3]

Released in drift_dev version 2.34.4.

[ViveNoctem]

@simolus3

Thanks! I'm still not entirely sure why we'd sometimes generate it as a boolean literal or a expression, but I agree it makes sense to treat TRUE and 1 as equal for default constraints.

I'm a bit late, but a few weeks ago, I looked into this with git bisect.
This commit seems to have changed the behavior.
45716ab
But I didn't have the time to look further into it back then.