Re-publishing an UNCHANGED module over its existing tables (a routine regen republish on a live dev instance) fails the schema UPDATE phase in two independent ways, both absent on a clean first publish:
- False incompatible change:
SchemaUpdateProcessor - Incompatible change of table [X] by adding a column [NOTE] which is [of type VARCHAR to be changed to CLOB] — the intent field is unchanged between publishes; the diff compares the live H2 column against the schema artefact and misreads the text/CLOB representation as a type change.
- Unsupported JDBC type:
TopologyWrapper - Complete failed in this cycle: Type [2014] not supported — H2 reports an existing timestamp column back as TIMESTAMP_WITH_TIMEZONE (JDBC 2014), which the update processor's supported-type map lacks ({1=CHAR, 2=NUMERIC, ..., 93=TIMESTAMP}), failing the whole schema artefact in phase UPDATE.
Both leave the (correct, pre-existing) tables in place, so the failure is noisy rather than destructive — but it makes every re-publish log ERRORs that must be hand-triaged, and a REAL incompatible change would drown among the false ones. Requests: treat same-logical-type text/CLOB (and TIMESTAMP/TIMESTAMPTZ) comparisons as equal in the diff, and add 2014 (and friends: 2013 TIME_WITH_TIMEZONE) to the supported map.
Observed on a re-publish sweep over ~50 modules: the two errors above fired for tables whose defining artefacts were byte-identical between the publishes.
🤖 Generated with Claude Code
Re-publishing an UNCHANGED module over its existing tables (a routine regen republish on a live dev instance) fails the schema UPDATE phase in two independent ways, both absent on a clean first publish:
SchemaUpdateProcessor - Incompatible change of table [X] by adding a column [NOTE] which is [of type VARCHAR to be changed to CLOB]— the intent field is unchanged between publishes; the diff compares the live H2 column against the schema artefact and misreads the text/CLOB representation as a type change.TopologyWrapper - Complete failed in this cycle: Type [2014] not supported— H2 reports an existing timestamp column back asTIMESTAMP_WITH_TIMEZONE(JDBC 2014), which the update processor's supported-type map lacks ({1=CHAR, 2=NUMERIC, ..., 93=TIMESTAMP}), failing the whole schema artefact in phase UPDATE.Both leave the (correct, pre-existing) tables in place, so the failure is noisy rather than destructive — but it makes every re-publish log ERRORs that must be hand-triaged, and a REAL incompatible change would drown among the false ones. Requests: treat same-logical-type text/CLOB (and TIMESTAMP/TIMESTAMPTZ) comparisons as equal in the diff, and add 2014 (and friends: 2013 TIME_WITH_TIMEZONE) to the supported map.
Observed on a re-publish sweep over ~50 modules: the two errors above fired for tables whose defining artefacts were byte-identical between the publishes.
🤖 Generated with Claude Code