DanielLeens commented on issue #11802:
URL: https://github.com/apache/seatunnel/issues/11802#issuecomment-5307587413
Thanks for describing the Doris multi-table overwrite case. I checked the
current `dev` save-mode path before replying.
The current Doris sink does not treat this as one global pre-sync hook.
Save-mode handling is table-scoped: `DROP_DATA` maps to truncating the current
target table, `RECREATE_SCHEMA` maps to dropping and recreating the current
target table, and `CUSTOM_PROCESSING` executes `custom_sql` for the current
target table through the standard save-mode handler.
For the multi-table case, the first thing I would try is table placeholders
in the sink config rather than one fixed SQL literal, for example:
```hocon
data_save_mode = "CUSTOM_PROCESSING"
custom_sql = "TRUNCATE TABLE ${table_full_name}"
```
or `${database_name}` / `${table_name}` if you need to build the target name
manually. The current sink factory path does run per-table placeholder
replacement on string options before each sink instance is created, and Doris
does not exclude `custom_sql` from that replacement path.
If you only need truncate-before-write for each current target table,
`data_save_mode = "DROP_DATA"` is the simpler built-in path on current `dev`.
If you still see it fall back to `APPEND_DATA`, please update the issue in
English and add:
1. the exact multi-table sink config you used;
2. the startup logs that show `APPEND_DATA`;
3. whether the target table name is static, `${table_name}`, or
`${table_full_name}`.
With that, maintainers can verify whether this is a config/path mismatch or
a real Doris multi-table bug.
--
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]
