Actually, yes. I have a job already running with "FieldSerializer" in
production. Any insights will be appreciated.
On Sat, Jun 23, 2018 at 7:39 AM, Vishal Santoshi
wrote:
> Thanks.
>
> On Thu, Jun 21, 2018 at 4:34 AM, Tzu-Li (Gordon) Tai
> wrote:
>
>> Hi Vishal,
>>
>> Kryo has a serializer
Thanks.
On Thu, Jun 21, 2018 at 4:34 AM, Tzu-Li (Gordon) Tai
wrote:
> Hi Vishal,
>
> Kryo has a serializer called `CompatibleFieldSerializer` that allows for
> simple backward compatibility changes, such as adding non-optional fields /
> removing fields.
>
> If using the KryoSerializer is a
Hi Vishal,
Kryo has a serializer called `CompatibleFieldSerializer` that allows for simple
backward compatibility changes, such as adding non-optional fields / removing
fields.
If using the KryoSerializer is a must, then a good thing to do is to register
Kryo's `CompatibleFieldSerializer` as
Hi Vishal,
In general, Kryo serializers are not very upgrade friendly.
Serializer compatibility [1] might be right approach here, but Gordon (in
CC) might know more about this.
Best, Fabian
[1]
Any more insight?
On Wed, Jun 13, 2018, 3:34 PM Vishal Santoshi
wrote:
> Any ideas on the standard way ( or any roundabout way ) of doing a version
> upgrade that looks back ward compatible.
> The @FieldSerializer.Optional("0") actually does ignore the field (
> even if reset ) giving it the
Any ideas on the standard way ( or any roundabout way ) of doing a version
upgrade that looks back ward compatible.
The @FieldSerializer.Optional("0") actually does ignore the field ( even
if reset ) giving it the default value if kyro is used. It has to do with
the FieldSerializer behaves .
I have a running pipe with Window State in a class say
Class A{
long a;
}
It uses the default KryoSerializer
I want to add a field to
Class A {
long a;
long b;
}
I need to suspend with SP and resume with the new version of Class A
Is there a definite way to do this. I tried
Class
