> > Is it something that can be done in a major version release?
This seems like it would be a major version release of the specification, which I think we were trying to essentially avoid in any reasonable time frame. Is there no way to turn the warnings off? On Mon, Aug 2, 2021 at 2:11 PM Max Burke <m...@urbanlogiq.com> wrote: > 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 >
