luoyuxia commented on code in PR #199:
URL: https://github.com/apache/paimon-cpp/pull/199#discussion_r3800194251
##########
include/paimon/realtime/realtime_context.h:
##########
@@ -66,29 +65,12 @@ struct PAIMON_EXPORT RealtimePartitionBucket {
/// Largest committed offset for each partition-bucket.
using RealtimeOffsetMap = std::map<RealtimePartitionBucket, int64_t>;
-/// Memory indexer and its initial offset resolved from committed and retained
memory progress.
-struct PAIMON_EXPORT RealtimeMemIndexerState {
- /// Plugin instance associated with the requested partition-bucket.
- std::shared_ptr<MemIndexer> indexer;
- /// First offset after both committed rows and rows currently retained by
the indexer.
- int64_t initial_offset;
-};
-
-/// One partition-bucket and the immutable plugin view captured for a table
scan.
-struct PAIMON_EXPORT RealtimePartitionBucketView {
- /// Partition-bucket associated with this view.
- RealtimePartitionBucket partition_bucket;
- /// Plugin instance that creates readers from `read_view`.
- std::shared_ptr<MemIndexer> indexer;
- /// Immutable rows pinned for one query plan.
- std::shared_ptr<MemReadView> read_view;
-};
-
/// Shared context that owns the `MemIndexer` instances used by a real-time
writer.
///
-/// Applications share one context between `WriteContext` and `ScanContext`.
The context uses
-/// either the default Arrow implementation or an application-provided factory
and keeps each
-/// created indexer available across writes, prepare-commit operations, and
process-local reads.
+/// Applications share one context between `WriteContext`, `ScanContext`, and
`ReadContext`. The
+/// context uses either the default Arrow implementation or an
application-provided factory and
+/// keeps each created indexer available across writes, prepare-commit
operations, and
+/// process-local reads.
class PAIMON_EXPORT RealtimeContext {
Review Comment:
That makes sense to me for the scope of this PR. Keeping the operation-level
API is consistent with the current paimon-cpp design, and I do not think a
table-level abstraction needs to be introduced in this change.
My main concern is future extensibility. I hope the API can eventually allow
other realtime context/store implementations to integrate without requiring
implementation-specific changes across the write, scan, and read paths. This
does not need to be addressed in this PR, but it would be good to consider it
in the follow-up API design.
--
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]
