Forward and backward compatibility

[ghost]

From nathan.s...@gmail.com on March 25, 2010 02:11:19

Current Kryo object graph serializers (eg, FieldSerializer) use the Java
class definition as a schema. This reduces serialized size because the data
for an object's fields is written in a known order; there is no need to
write field identifiers. The drawback is that any change to the class
definition invalidates serialized bytes made with the old class definition.

Both scenarios should be supported. Some uses of Kryo have short-lived
serialized bytes (eg, IPC or a networked game) and gladly sacrifice
forward/backward compatibility for smaller serialized size. Other uses keep
serialized bytes around for a long time (eg, storing them on disk or in a
database) and it would be unacceptable to invalidate all existing data when
a class is modified.

To support forward/backward compatibility, during serialization, the first
time an object type is encountered the field names would be written. This
defines the order the field values will appear in the serialized bytes for
that type. If a field no longer exists, it is ignored. Fields not in the
serialized bytes are left unchanged.

It isn't terribly efficient to write the field name as Strings. Possibly an
annotation could be provided that would allow fields to be given an
ordinal, allowing the field to be referenced with just 1 byte rather than 1
byte per character in its name.

Original issue: http://code.google.com/p/kryo/issues/detail?id=12

[ghost]

From nathan.s...@gmail.com on March 25, 2010 21:12:05

A first draft for this issue is checked in, r85. The class is currently named
CompatibleFieldSerializer. It supports adding and/or removing fields, which does not
invalidate previously serialized bytes. Note that it does not support changing the
type of a field.

The overhead compared to FieldSerializer is the header that is output the first time
an object of the type is serialized. The header consists of an int for the number of
fields, then a String for each field name. Also, in order to support skipping the
bytes for a field that no longer exists, for each field value I had to write an int
that is the length of the value in bytes.

[ghost]

From nathan.s...@gmail.com on April 12, 2010 14:45:54

We've got tests and everything. Calling it good for now.

Status: Fixed

[ghost]

From dimec...@gmail.com on October 26, 2011 22:22:15

Hi, any examples how to use this ?