Re: Will that be a problem if POJO key type didn't override equals?

Hi Timo, Thanks a lot. I will try it out. Best Regards, Tony Wei 2018-02-06 17:25 GMT+08:00 Timo Walther : > With heap-based state I meant state that is stored using the > MemoryStateBackend or FsStateBackend [1]. In general, even if you are just > using ValueState, the key

Re: Will that be a problem if POJO key type didn't override equals?

With heap-based state I meant state that is stored using the MemoryStateBackend or FsStateBackend [1]. In general, even if you are just using ValueState, the key might be used internally to store your value state in hash table. I think the migration should work in your case. Otherwise feel

Re: Will that be a problem if POJO key type didn't override equals?

Hi Timo, Thanks for your response. I will implement equals for my POJO directly. Is that be okay instead of wrap it into another class? Furthermore, I want to migrate the states from the previous job. Will it lead to state lost? I run my job on Flink 1.4.0. I used RocksDBStateBackend and only

Re: Will that be a problem if POJO key type didn't override equals?

Hi Tony, not having a proper equals() method might work for a keyBy() (partitioning operation) but it can lead to unexpected side effects when dealing with state. If not now, then maybe in the future. For example, heap-based state uses a hash table data structures such that your key might

Will that be a problem if POJO key type didn't override equals?

Hi all, I have defined a POJO class that override Object#hashCode and used it in keyBy(). The pipeline looks good (i.e. no exception that told me it is UNSUPPORTED key types), but I'm afraid that it will leads to a problem that elements that I think have the same key will not get the same state