924060929 commented on code in PR #68934:
URL: https://github.com/apache/doris/pull/68934#discussion_r4255473949
##########
fe/fe-connector/fe-connector-iceberg/src/main/java/org/apache/doris/connector/iceberg/IcebergPartitionUtils.java:
##########
@@ -801,6 +828,11 @@ static boolean isValidRelatedTable(Table table) {
return false;
}
PartitionField partitionField = fields.get(0);
+ if (spec.schema().findType(partitionField.sourceId()).typeId() ==
Type.TypeID.TIMESTAMP_NANO) {
Review Comment:
Confirmed at `3f7020a33f405beaf37e5adbf07ccbb55a06774a`. This is on the
normal query path (`beginQuerySnapshot` → `latestSnapshotPin` →
`isValidRelatedTable`), so the impact extends beyond MTMV and nanos tables.
After the valid v1 remove-partition/drop-source lifecycle, the source type is
absent and this dereference fails before the existing transform exclusion.
Please treat an absent source type as ineligible for RANGE derivation and
retain the UNPARTITIONED view, with a snapshot-planning test selecting a
surviving column. Static source/dependency inspection only; I did not run tests.
##########
fe/fe-connector/fe-connector-paimon/src/main/java/org/apache/doris/connector/paimon/PaimonTypeMapping.java:
##########
@@ -156,6 +156,10 @@ private static ConnectorType toDecimalType(DecimalType
type) {
private static ConnectorType toTimestampType(DataType dataType) {
int scale = DEFAULT_TIMESTAMP_SCALE;
if (dataType instanceof TimestampType) {
+ // Keep all source fractional digits instead of truncating
high-precision wall-clock values.
+ if (((TimestampType) dataType).getPrecision() >
MAX_TIMESTAMP_SCALE) {
+ return ConnectorType.of("TIMESTAMP_NS");
Review Comment:
Confirmed at `3f7020a33f405beaf37e5adbf07ccbb55a06774a`: an existing Paimon
`TIMESTAMP(7/8/9)` value such as `1000-01-01` now reaches
`VectorColumn.appendTimestampNs` → `TypeNativeBytes.convertToTimestampNs`,
where checked multiplication overflows. Previously the DATETIMEV2(6) projection
retained access to that row. Please make the compatibility policy explicit
rather than silently narrowing existing tables' readable range—for example, an
explicit mapping option retaining the previous projection—and cover an actual
out-of-range historical row. The current precision-7/8 truncation fix addresses
fractional digits, but does not address this range change. Static inspection
only; I did not run tests.
--
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]
