davidzollo commented on PR #11029:
URL: https://github.com/apache/seatunnel/pull/11029#issuecomment-5579562787
Resolved the merge conflict against `dev` and pushed `f561cad5e13`. This one
needed real reconciliation, not a mechanical merge, so here's the full trail:
**What collided**: `dev` had independently merged apache/seatunnel#11922
("Support PostgreSQL CDC ADD COLUMN schema evolution") directly onto the
pre-refactor `PostgresIncrementalSource`/`PostgresSourceConfigFactory` — adding
`include.schema.changes` wiring, a `PostgresRelationSchemaChangeResolver`,
`createDebeziumDeserializationSchema` overrides for RELATION-message schema
tracking, and `SupportSchemaEvolution` + `ADD_COLUMN` support — while this
branch had already refactored those same two classes onto the new
`PgBaseIncrementalSource`/`PgBaseSourceConfigFactory` template-method base this
PR introduces. Both sides touched the same methods for different reasons.
**How I reconciled it, method by method:**
- `PgBaseIncrementalSource.createDebeziumDeserializationSchema` already
covers everything dev's version did *except* the two PostgreSQL-specific calls,
`setSchemaChangeResolver(new PostgresRelationSchemaChangeResolver())` and
`setSchemaChangeEventFilter(...)`. Rather than duplicate the whole method,
`PostgresIncrementalSource` now overrides it to call the inherited
`loadTableChanges()` (which reuses the already-constructed dialect, unlike
dev's version which built a redundant second one) and adds just those two
Postgres-specific builder calls on top — kept out of the shared base since
OpenGauss isn't guaranteed to share PostgreSQL's RELATION-message wire format.
- `PostgresIncrementalSource` now also `implements SupportSchemaEvolution`
(in addition to `SupportParallelism`, inherited from the base) and carries
dev's `supports()` (`ADD_COLUMN`) and `validateSchemaEvolutionOptions` (schema
evolution requires `pgoutput`) unchanged.
- For `PostgresSourceConfigFactory`, I checked
`PgBaseSourceConfigFactory.create()` line by line against dev's inline version:
`table.include.list` parsing, `dbzProperties` passthrough, `snapshot.mode`
handling and `enableConcurrentRead` propagation were all already identically
present in the base (the comment on the concurrent-read line literally reads
"Keep the concurrent-read flag wired after moving concrete connectors onto
PG-base" — this was anticipated). The one real gap: the base hardcoded
`include.schema.changes` to `false` instead of the actual
`schema-changes.enabled` value, which would have silently broken the whole
ADD_COLUMN feature for every PG-base connector, not just Postgres. Fixed at the
base-class level (so OpenGauss gets it too) and kept dev's explicit ordering —
applied after the `dbzProperties` merge, not before, so SeaTunnel's own option
stays authoritative over a raw passthrough that happens to set the same key.
- `PostgresSourceConfigFactory`'s own conflict resolved to keeping this
branch's template-method overrides (`driverClassName`,
`configureConnectorProperties`, `createSourceConfig`) as-is, since the base now
fully subsumes what dev's inline version did.
Everything dev's `PostgresDialect.java`,
`PostgresSourceFetchTaskContext.java`,
`PostgresRelationSchemaChangeResolver.java`,
`RelationAwarePostgresSchema.java`, `PostgresIncrementalSourceFactory.java` and
`PostgresTypeUtils.java` changes added merged cleanly with no conflicts, so
they're untouched by me.
**Tests**: added `shouldEnableSchemaChangesWhenSchemaEvolutionIsEnabled`,
`shouldDisableSchemaChangesByDefault` and
`shouldKeepSchemaChangesEnabledAuthoritativeOverUserDebeziumProperties` to
`PostgresSourceConfigFactoryTest`, since nothing in the existing suite asserted
on `include.schema.changes` at all — that gap is exactly what let the
base-class hardcoding go unnoticed by tests.
Separately, on the SNAPSHOT_ONLY blocker from your 2026-08-25 review: it's
already fixed on this head (`getStartupModeOption` /
`OpengaussSourceOptions.STARTUP_MODE` restoring `SNAPSHOT_ONLY`, matching the
docs) — that predates my involvement here, so no action needed from me there;
flagging only that it's still present after the merge and unaffected by the
conflict resolution.
`./mvnw spotless:apply` run on `connector-cdc-pg-base`,
`connector-cdc-postgres` and `connector-cdc-opengauss` before pushing. Per the
SeaTunnel local-verification rule I'm not running the modules' tests locally —
GitHub CI on this head is the verification source of truth, and given the depth
of this reconciliation I'd treat that CI result as load-bearing before merge.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
