Schema evoluntion in Flexbuffers?

[tisonkun]

I'm using Flexbuffers Rust now. And I wonder if it supports schema evolution.

That is, now I have a struct:

#[derive(Debug, Clone, Serialize, Deserialize)]
struct EntryData {
    data: Vec<u8>,
}

And maybe I'll later extend it to:

#[derive(Debug, Clone, Serialize, Deserialize)]
struct EntryData {
    kvs: HashMap<String, String>,
    data: Vec<u8>,
}

Will the bytes encodes with the previous struct can be decoded to the later one?

[Advait251206]

FlexBuffers is a bit different from FlatBuffers in this regard because it is schema-less. There isn't a formal schema evolution mechanism with field IDs, deprecations, defaults, etc., like you get with FlatBuffers.

That said, whether your example works depends largely on how the Rust serialization layer handles missing fields during deserialization.

If older data is encoded as something equivalent to:

{
  "data": [...]
}

and newer code expects:

{
  "kvs": {...},
  "data": [...]
}

then deserialization will only succeed if the new field is treated as optional or has a default value. For example:

#[derive(Debug, Clone, Serialize, Deserialize)]
struct EntryData {
    #[serde(default)]
    kvs: HashMap<String, String>,
    data: Vec<u8>,
}

With #[serde(default)], older payloads that don't contain kvs can still deserialize successfully, and kvs will be initialized as an empty map.

More generally, FlexBuffers tends to be tolerant of:

• Adding optional fields.
• Ignoring unknown fields.
• Reading subsets of available data.

The main compatibility concern is usually the behavior of the serializer/deserializer framework (Serde in this case), rather than FlexBuffers itself.

So for your specific example, I'd expect backward compatibility to work as long as the new field has a sensible default or is represented as an Option<T>. Without that, deserialization of older payloads may fail because the required field is missing.