suxiaogang223 commented on code in PR #68837:
URL: https://github.com/apache/doris/pull/68837#discussion_r4244434204
##########
gensrc/thrift/PlanNodes.thrift:
##########
@@ -395,9 +396,13 @@ struct TPaimonFileDesc {
16: optional i64 schema_id; // for schema change.
// Reader implementation for logical paimon split. Native file split uses
range format type.
17: optional TPaimonReaderType reader_type;
+ // Reserved for the Paimon Rust reader. Keep these ids aligned with
branch-4.1.
+ 18: optional string paimon_table_schema_json
+ 19: optional string paimon_branch
// Original Paimon RawFile.path() before Doris storage path normalization.
Native readers use this
- // to materialize the public file-location metadata column.
- 18: optional string original_file_path;
+ // to materialize the public file-location metadata column. This
master-only field is appended after
+ // the branch-4.1 fields instead of reusing field 18.
+ 20: optional string original_file_path;
Review Comment:
Thanks for raising this. We intentionally do not preserve compatibility with
the unreleased intermediate master implementation that used field 18 for
`original_file_path`. The supported upgrade boundary is the released branches:
branch-4.2 already assigns fields 18 and 19 to `paimon_table_schema_json` and
`paimon_branch`. Master therefore keeps those published meanings and appends
the master-only `original_file_path` as field 20. Arbitrary master-to-master
rolling upgrades are not a supported compatibility boundary before release.
##########
gensrc/thrift/FrontendService.thrift:
##########
@@ -339,8 +339,8 @@ struct TReportExecStatusParams {
33: optional string first_error_msg
- // Opaque, connector-owned commit fragments; FE routes them to the
transaction.
- 34: optional list<binary> connector_commit_data
+ // Paimon commit messages prepared by BE and committed by FE.
+ 34: optional list<DataSinks.TPaimonCommitMessage> paimon_commit_messages
Review Comment:
Thanks for raising this. The `list<binary>` form existed only in an
unreleased intermediate master implementation. Both branch-4.1 and branch-4.2
use field 34 as `list<TPaimonCommitMessage>`, so master must retain that
published meaning to support the released-branch-to-master upgrade path. We do
not need wire compatibility between arbitrary unreleased master commits.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]