[
https://issues.apache.org/jira/browse/FLINK-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15895667#comment-15895667
]
Jayson Minard edited comment on FLINK-5964 at 3/4/17 1:11 PM:
--------------------------------------------------------------
This isn't just about Immutable types, its really about anything that can do
special steps on construction:
* no default constructor, but constructors with parameter names known
* decide between multiple constructors based on input available
* constructors that can accept all or some of the property values
* mixed model of constructor + field setting
* respecting and understanding nullable types
* respecting and understanding default values (maybe other calculated fields)
Most of these issues can not be solved in the current Flink instance creation
model. For Kotlin, we handle all of these cases for example in the
Jackson-Kotlin-Module. There we basically have a custom instantiator that has
enough information passed in to do the job, and in cases where it sees nothing
special, it falls back to the POJO instantiator.
was (Author: jayson.minard):
This isn't just about Immutable types, its really about anything that can do
special steps on construction:
* decide between multiple constructors based on input available
* constructors that can accept all or some of the property values
* mixed model of constructor + field setting
* respecting and understanding nullable types
* respecting and understanding default values (maybe other calculated fields)
Most of these issues can not be solved in the current Flink instance creation
model. For Kotlin, we handle all of these cases for example in the
Jackson-Kotlin-Module. There we basically have a custom instantiator that has
enough information passed in to do the job, and in cases where it sees nothing
special, it falls back to the POJO instantiator.
> Change TypeSerializers to allow construction of immutable types
> ---------------------------------------------------------------
>
> Key: FLINK-5964
> URL: https://issues.apache.org/jira/browse/FLINK-5964
> Project: Flink
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0.0
> Reporter: Jayson Minard
> Priority: Minor
>
> If your programming language has a lot of Immutable types (and with no
> default constructor) Flink forces you to create new versions as read/write
> POJO otherwise the types are rejected by the system. In Kotlin for example,
> given a class and property values we can determine which constructor to call
> and invoke it using knowledge of default values, nullable types and which
> properties can be set in construction or after construction.
> Flink provides no opportunity to use this model because Serializers are
> littered with calls to `createInstance` that are not passed any values so
> have no opportunity to fully inflate the object on construction.
> This means that when you use Flink you throw away maybe hundreds of state
> objects (my worst case) and have to create Flink-only variations which
> becomes grunt work that adds no value.
> Currently TypeExtractor isn't extendable, and all of the special cases are
> hard coded. It should be configured the order of checking for type
> information so that pluggable types can be added into the chain of analysis.
> For example before `analyzePojo` is called I could special case a Kotlin
> class returning a different TypeInformation instance. But I don't think that
> solves the whole problem since other TypeSerializers make assumptions and
> call `createInstance` on other TypeSerializers without knowing how they would
> want to do the construction (in the Kotlin case it would be "tell me to
> construct my instance and give me the list of named fields and serializers to
> get their values and let me decide what to do).
> What is the best idea for this change? With guidance, I can work on the PR.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
