docu for schema evolution best practice

[tweakmy]

Hi there,
Is there any articles or docu somewhere that describe the schema evolution? or any best practice of schema evolution using flatbuffer. Thanks.

[Wouter van Oortmerssen]

https://google.github.io/flatbuffers/md__schemas.html

Under "tables" and also under "gotchas" at the end. This document should answer your questions about schema evolution, if anything is unclear, please tell me, and I will enhance this document.

On Mon, Jul 13, 2015 at 10:47 PM, tweakmy <liew...@gmail.com> wrote:

Hi there,
Is there any articles or docu somewhere that describe the schema evolution? or any best practice of schema evolution using flatbuffer. Thanks.

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mozart]

Hi all,
I am not clear how to use schema evolution? Can you enhance this document more detail or better, give me an example. Thanks!

[Wouter van Oortmerssen]

Can you ask more specific question as to what is not addressed by the documentation mentioned above?

Quick example:

Original schema: table { a:int; b:int; }

Ok: table { a:int; b:int; c:int; }

Not ok: table { c:int a:int; b:int; }

Ok: table { c:int (id: 2); a:int (id: 0); b:int (id: 1); }

Not Ok: table { b:int; c:int; }

Ok: table { a:int (deprecated); b:int; c:int; }

Maybe Ok: table { a:uint; b:uint; }  // same-size type change

[Hải Nguyễn]

FlatBuffers documentation says that its schema supports both forward and backward compatibility.

From what you posted, I understand that forward compatibility means to add new field at the end of schema. Backward compatibility means to mark a field to be deprecated.

Do I understand correctly? If not, please help me clarify the meaning of backward and forward compatibility.

Thank you.

Hai

[Wouter van Oortmerssen]

"backwards compatibility" means that code compiled with a newer schema can read old data. "forwards compatibility" means that an older program can read newer data.

Adding or deprecating fields applies to both of those cases.

newer program, older data, new field: get default.

newer program, older data, deprecated field: you can't read the field anymore.

older program, newer data, new field: field is ignored.

older program, newer data, deprecated field: get default.

[Wouter van Oortmerssen]

This is now part of the documentation:

https://github.com/google/flatbuffers/commit/f8c1980fdff1a6985e7346efe84656139b600aaa