Is it something that can be done in a major version release? On our project we extensively use flatbuffer schema definitions and have incorporated the Arrow ones so our builds are littered with these warnings and it would be nice to see them disappear!
On Mon, Aug 2, 2021 at 9:07 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > I'm -0.5. > > We never got it merged but I think at least some people might be relying on > JSON serialized versions of flatbuffers schemas (and I would guess this > would break that, or at least it is something we should test). While I > like consistency and the warnings might be annoying, I'd rather keep it > the way it is as I think the effort to fix (and potential impact) outweighs > the benefits. > > > > On Mon, Aug 2, 2021 at 6:34 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > While I'm not fond of changing naming conventions because of a > > third-party project, in this case we have inconsistent naming in our > > .fbs files, so this could be an opportunity to clean it up. > > > > > > Le 02/08/2021 à 15:00, Wes McKinney a écrit : > > > While doing some Flatbuffers work, I noticed that recent compiler > > > versions now warn about non-snake-case field names: > > > > > > https://github.com/google/flatbuffers/pull/6005 > > > > > > It seems that the intent is for the compiler to generate > > > "language-friendly" code (e.g. camelCase for Java) from snake_case > > > schemas. It looks like Arrow won't be disrupted by this warning, but I > > > am wondering if this is something that we might be able to fix at some > > > point. Because the field names do not impact the binary format of the > > > Flatbuffers, this would be backward and forward compatible, but it > > > would require some code changes in various bindings (e.g. C++, but > > > probably not Java). > > > > > > -- -Max
