Au-Miner commented on PR #28671: URL: https://github.com/apache/flink/pull/28671#issuecomment-4932908437
> That’s my only remaining concern. Please let me know what you think. Thanks, this is a fair concern. I think the heart of the problem is whether the bundle can prove the identity of the row whose history it is compressing. In JoinKeyContainsUniqueKeyBundle and InputSideHasUniqueKeyBundle, the records in this example are associated with the same stable key. Since +I and -U cancel inside the bundle and are never emitted downstream, the remaining +U is the first visible accumulate event for that key. Therefore, it can be safely normalized to +I. InputSideHasNoUniqueKeyBundle has no stable row identity. It treats records as multiset deltas and can only match them by their complete row values. It can cancel +I(old) with -U(old), but it cannot prove that a later +U(new) belongs to the same logical row. Duplicate or interleaved updates could make a conversion based only on adjacency incorrect, so the original +U is preserved. Moreover, this pull request (PR) aims to address the rowKind issue encountered in mini-batch mentioned in JIRA. This is a common problem with the MiniBatch feature, which does not affect the final result. For the sake of distinguishing the identity of the row, I did not aggressively update the behavior of +I-U+U under noUniqueKey to +I. -- 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]
