Hi Zakelly,
Adding such "rich" constructs is fair point, we can keep things internal.
I've a rough feeling what that would mean and we can discuss the details on
a PR.
> BTW, I'm curious if there is a solution for implementing a Source V2 based
on `InputFormat`. Otherwise if the `InputFormat` is
Hi Gabor,
To be more specific, I'm thinking of introducing `RichSourceReaderContext`,
and having a `RichSourceReaderFactory` creating `SourceReader` on top of
the rich context. Or we still use the `SourceReaderFactory` but do type
conversion from `SourceReaderContext` to `RichSourceReaderContext`
Hi Zakelly,
Before we go into any details I can say that if we can expose the less the
better so agree with you on the direction.
On the technical level not yet understand what exactly you're suggesting.
`RichInputFormat` is a \@Public API
where we expose `RuntimeContext` now on V1. I would like
Hi Gabor,
Good point for the migration.
I took a brief look. I thought the `RuntimeContext` is too powerful and
might not be suitable to expose on \@Public API. Is it possible to
introduce another 'rich' code path just like the difference between
`RichInputFormat` and `InputFormat`, and keep that
