fresh-borzoni commented on issue #311: URL: https://github.com/apache/fluss-rust/issues/311#issuecomment-3900451757
@zuston Thanks for the sketch! I’d avoid unifying log scan + limit/KV scan behind one BatchScanner: they have different semantics/lifecycles (log = long-lived offset/stream polling, limit = one-shot RPC), and a shared ScanOptions bag creates invalid combos we’d have to validate at runtime. Hiding that behind a shared `poll()` would blur semantics for callers, and in Rust it’s also awkward to express as a reusable dyn trait without boxing futures or async-trait I’d suggest implementing LimitBatchScanner as a standalone type (mirroring the Java LimitScan RPC). We can unify at the DataFusion layer (RecordBatchStream) and only extract shared internals later if a real common surface emerges. -- 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]
