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
Hi All,
I've just had a look at it how it would be possible to migrate state
processor API from source v1 to source v2 API.
The whole concept in the state processor API actual implementation is based
on to get
RuntimeContext from RichInputFormat [1] which then allows us to access
state backend,
k
