jordepic opened a new pull request, #8146: URL: https://github.com/apache/paimon/pull/8146
### Purpose (This change is just a bug fix, it should not have further implications) RemoteTableQuery built its lookup-key serializer from the table's full primary keys (table.primaryKeys()), but the lookup contract (PrimaryKeyPartialLookupTable#get) passes lookup() the trimmed primary key (primary keys minus partition keys -- the native LSM key within a (partition, bucket)). For a partitioned primary-key table these differ, so the serializer reads the wrong fields: it interprets field 0 of the trimmed key as the first full-PK field. When the partition key and trimmed key happen to share a type this silently produces a usable key (the extra trailing field is ignored on the server side), which is why it went unnoticed for unpartitioned tables and same-type keys. When the types differ -- e.g. PRIMARY KEY (pt INT, k STRING) PARTITIONED BY (pt), where the trimmed key is (k STRING) -- it throws ClassCastException in InternalRowSerializer.toBinaryRow. The local executor (LocalTableQuery) consumes the trimmed key natively, so only the remote path is affected. Build keySerializer from schema().trimmedPrimaryKeys() instead, matching the key the caller actually provides. Unpartitioned tables are unaffected, since trimmed primary keys equal the full primary keys there. ### Tests Add RemoteLookupJoinITCase#testLookupPartitionedRemoteTable covering a partitioned table with a differently-typed trimmed key; it fails with the ClassCastException before this change and passes after. -- 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]
