Re: Clarification of TypesSerializers

2017-07-16 Thread Tzu-Li (Gordon) Tai
Hi Dawid, It would be possible to make this work by reconfiguring the serializer to be able to read both “old” and “new” formats, and write in only the new format, and just return `CompatibilityResult.compatible()`. Note that this typically isn’t recommended, since if you’re using RocksDB backe

Re: Clarification of TypesSerializers

2017-07-10 Thread Dawid Wysakowicz
Hi Gordon, Thanks for your response. Generally speaking, I wanted to do what you wrote in the second mail, when I first had a look at the TypeSerializer interface. So I think it really makes sense :) As you said the requiresMigration does not work right now, I tried looking for some workaround

Re: Clarification of TypesSerializers

2017-07-07 Thread Tzu-Li (Gordon) Tai
Some extra information after understanding your case a bit more: What you would need to do, is to return a `CompatibilityResult#requiresMigration(convertSerializer)`, where the `convertSerializer` is a serializer that does read the extra information. The `convertSerializer` will only ever be use

Re: Clarification of TypesSerializers

2017-07-07 Thread Tzu-Li (Gordon) Tai
Hi Dawid, First of all, one thing to clarify: TypeSerializer#ensureCompatibility is invoked on the new provided state serializer. Also, a reconfigured compatible serializer should NOT have different serialization formats (that would require state migration, i.e. return CompatibilityResult#requi