Any of the dependent message types constituting an IPC stream or file are not interpretable without the Schema message, so the Schema basically "governs" the other messages. So it is sufficient to examine the features only once at schema resolution time, and attaching features to a RecordBatch message is not necessary (and maybe it would be weird to have the field set only in Schema message types but then null for other message types). That's perhaps not a completely persuasive argument about why version and features are not contained in the same Flatbuffers table.
Another argument I can see is that the version number at the Message level provides an "escape hatch" for non-forward-compatible alterations of message types, even at the binary level. Having it at the Message level also spares applications from having to set the version in multiple places rather than a single place. On Fri, Jul 17, 2020 at 4:23 PM Antoine Pitrou <anto...@python.org> wrote: > > > Hello, > > A bit too late, I noticed the new "features" field is defined on the > Schema table, while the "version" field is defined on the Message table. > Since both fields have closely related purposes (notify the reader of > the conventions used in the stream), I'm a bit surprised that they're > present at different places. Is there a reason I missed for this > seeming inconsistency? > > Regards > > Antoine.
