gaborgsomogyi commented on PR #26521: URL: https://github.com/apache/flink/pull/26521#issuecomment-2858407310
> > > @gaborgsomogyi I was reading the flip an was expecting a generic mechanism, but the Pr is Avro specific. Did I misunderstand ? I think it would be helpful to have Avro in the title of the PR. > > > > > > Avro is just an example. What blocks one to add any generic type? > > I am seeing an Avro specific addition to the state. So it does not look like a general mechanism to add generic types. If I wanted to add a generic type I would need to change the StatefulFunction to add another line like. private ValueState myNewState; > > I was expecting in the StatefulFunction something like : `private ValueState<GenericTypeRecord> myNewState;` where GenericTypeRecord is a new Flink interface to add one new generic type. Then we would also want the ability to be able to specify any number of these new generic types, so a collection of ValueStates or maybe a MapState. > > Then have a pluggable Avro implementation of this Flink interface. It does not seem right to tie a serialisation implementation like Avro to the stateful function. We have a Kryo dependancy in our serialisation which has caused us issues when trying to change the Kryo version. I would prefer to have a level abstraction do avoid the direct Avro dependancy. > > WDYT? I can't really imagine more flexible approach than `bring your own serializers/libraries and use them as you wish`. Again, avro here is just an example in the `TEST` area. If you're afraid of direct avro dependency (state processor API uses avro `ONLY` in test) then build `GenericTypeRecord` or any kind of additional layer on user side. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
