DanielLeens commented on issue #11878:
URL: https://github.com/apache/seatunnel/issues/11878#issuecomment-5341928037
Thanks for spelling the use case out so concretely. I do think the
underlying need is real: for multi-table generated-SQL jobs, people often need
the upstream primary key plus one shared static field such as `tenant_id` or
`data_source`.
That said, I would not merge this by overloading `primary_keys` with two
different grammars inside the same list. Today the documented contract is still
a plain array, and placeholder expansion only supports `${primary_key}` when it
is the only element. Encoding per-table routing rules inside that same list
would make one option carry both `final key list` and `table matching logic`,
which becomes hard to validate, document, and keep backward-compatible.
My recommendation is:
1. keep current `primary_keys` behavior unchanged for backward compatibility;
2. introduce a separate explicit option for table-specific key mapping,
instead of hiding a second syntax inside `primary_keys` itself;
3. make precedence and fallback explicit in that new option rather than
relying on string parsing conventions;
4. cover the interaction with `${primary_key}`, generated SQL, auto-created
tables, and docs in both English and Chinese.
So from process perspective, I would prefer a short design discussion in
this issue first, then a focused PR. If you want to contribute it, the next
useful update here would be a concrete option shape plus 2-3 examples of
precedence / fallback behavior when both the new mapping option and the
existing `primary_keys` setting are present.
--
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]
