linliu-code commented on code in PR #13115:
URL: https://github.com/apache/hudi/pull/13115#discussion_r2037939187
##########
hudi-common/src/main/java/org/apache/hudi/common/table/read/FileGroupRecordBuffer.java:
##########
@@ -504,6 +529,19 @@ protected Option<T> merge(Option<T> older, Map<String,
Object> olderInfoMap,
}
}
+ /**
+ * Decides whether to keep the incoming record with ordering value
comparison.
+ */
+ private boolean shouldKeepNewerRecord(Option<T> oldVal, Map<String, Object>
oldMetadata, Option<T> newVal, Map<String, Object> newMetadata) {
+ Comparable newOrderingVal = readerContext.getOrderingValue(newVal,
newMetadata, readerSchema, orderingFieldName);
+ if (isDeleteRecordWithNaturalOrder(newVal, newOrderingVal)) {
+ // handle records coming from DELETE statements(the orderingVal is
constant 0)
+ return true;
+ }
+ Comparable oldOrderingVal = readerContext.getOrderingValue(oldVal,
oldMetadata, readerSchema, orderingFieldName);
+ return newOrderingVal.compareTo(oldOrderingVal) >= 0;
Review Comment:
My assumption about orderingValue is > 0 since ordering field is generally
ts, and only delete could have ordering value = 0. Therefore, L542 favors new
records.
But if the ordering field could be a random column, then for delete, we
probably need to handle delete differently from here.
So my question is: which case should we really worry about in Hudi?
orderingValue > 0, or any values. Remember the orderingField can be a string
also.
--
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]
