lxy-9602 commented on code in PR #269:
URL: https://github.com/apache/paimon-cpp/pull/269#discussion_r3914645795
##########
src/paimon/core/realtime/realtime_primary_key_writer.cpp:
##########
@@ -245,15 +235,14 @@ Result<CommitIncrement>
RealtimePrimaryKeyWriter::PrepareCommit(bool wait_compac
return increment;
}
-Status RealtimePrimaryKeyWriter::FlushSegment(const
std::shared_ptr<RealtimeSegmentHandle>& segment,
- const OffsetRange&
sealed_offsets) {
+Status RealtimePrimaryKeyWriter::FlushSegment(
+ const std::shared_ptr<RealtimeSegmentHandle>& segment) {
PAIMON_ASSIGN_OR_RAISE(std::vector<std::unique_ptr<BatchReader>> readers,
realtime_store_->CreateCommitReaders(segment));
Review Comment:
Agreed that we can compare the total number of rows emitted by the raw
commit readers with `segment->GetRowCount()`, consistent with the append path.
While I don’t think core should revalidate `_REALTIME_OFFSET` uniqueness or
range here. `RealtimeStore::CreateCommitReaders` already requires
implementations to expose every sealed row exactly once, similar to how core
trusts other plugin (e.g., file-format readers) to return correct field values.
Offset uniqueness would also require additional state because PK readers are
sorted by key and sequence rather than offset.
Even comprehensive offset validation cannot prove that the plugin returned
the correct row contents or associated each offset with the correct mutation.
Extending validation in this direction would effectively make core revalidate
the plugin’s entire output, which is inconsistent with the trust boundary used
for other plugin. A custom store violating this contract should be treated as a
plugin bug.
--
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]
