You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Wes McKinney <we...@gmail.com> on 2021/08/02 13:00:00 UTC
Recent Flatbuffers warns about non-snake-case field names
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).
Re: Recent Flatbuffers warns about non-snake-case field names
Posted by Wes McKinney <we...@gmail.com>.
flatc does have the option to disable warnings (--no-warnings)
On Tue, Aug 3, 2021 at 2:26 PM Micah Kornfield <em...@gmail.com> wrote:
>
> >
> > 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 <ma...@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 <em...@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 <an...@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
> >
Re: Recent Flatbuffers warns about non-snake-case field names
Posted by Micah Kornfield <em...@gmail.com>.
>
> 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 <ma...@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 <em...@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 <an...@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
>
Re: Recent Flatbuffers warns about non-snake-case field names
Posted by Max Burke <ma...@urbanlogiq.com>.
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 <em...@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 <an...@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
Re: Recent Flatbuffers warns about non-snake-case field names
Posted by Micah Kornfield <em...@gmail.com>.
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 <an...@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).
> >
>
Re: Recent Flatbuffers warns about non-snake-case field names
Posted by Antoine Pitrou <an...@python.org>.
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).
>