Akash3121 commented on code in PR #10111:
URL: https://github.com/apache/paimon/pull/10111#discussion_r4089797257
##########
paimon-python/pypaimon/table/system/files_table.py:
##########
@@ -125,6 +125,24 @@ def _render_partition(partition_row) -> Optional[str]:
for field, value in zip(fields, values))
+def _row_values(row) -> List[Any]:
+ # ``GenericRow`` exposes ``values`` directly, but a row read back from a
+ # manifest is a ``BinaryRow`` that only offers ``get_field``/``__len__``.
+ # Fall back to those so value stats are not silently rendered as ``{}``.
+ if row is None:
+ return []
+ values = getattr(row, "values", None)
+ if values is not None:
+ return values
+ try:
+ return [row.get_field(i) for i in range(len(row))]
+ except Exception:
Review Comment:
This broad catch turns every stats decoding failure into a valid-looking
`{}` result. For example, if `BinaryRow.get_field()` raises because the
manifest bytes are malformed, a type cannot be decoded, or the resolved fields
do not match the stored row, `$files` silently reports empty statistics - the
same success-shaped symptom this PR is fixing. Java’s `FilesTable` does not
suppress these decoding failures.
Please let the actionable exception propagate, or catch only a specifically
expected compatibility condition and surface it with the affected file/schema
context. A focused test can use a row whose `get_field()` raises and assert
that `_row_values` does not return `[]` .
--
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]
