You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "David Li (Jira)" <ji...@apache.org> on 2021/12/01 22:30:00 UTC

[jira] [Commented] (ARROW-14771) [C++][FlightRPC] Consider exposing Protobuf types

    [ https://issues.apache.org/jira/browse/ARROW-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17452049#comment-17452049 ] 

David Li commented on ARROW-14771:
----------------------------------

Some notes:
 * The symbol that needs to be exported is {{{}descriptor_table_Flight_2eproto{}}}, unfortunately adding {{__attribute__((visibility("default")))}} and/or adjusting the linker script doesn't help (nm still shows that the resulting symbol is private).
 * The symbol name is dependent on the import path, i.e. you must import Flight.proto as {{{}import "Flight.proto"{}}}.
 * How will this work with generators like buf? We need to document how to configure the generator such that it uses Flight.proto for imports but does not generate code for it.
 * We need to install Flight.pb.h which is a problem…we may have to adjust the import path so the header gets exposed under a reasonable path.

> [C++][FlightRPC] Consider exposing Protobuf types
> -------------------------------------------------
>
>                 Key: ARROW-14771
>                 URL: https://issues.apache.org/jira/browse/ARROW-14771
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: C++, FlightRPC
>            Reporter: David Li
>            Priority: Major
>
> For applications working with both Flight and gRPC, where the gRPC service wishes to use Flight types, currently you'll run into conflicts at link time or runtime: libarrow_flight doesn't appear to expose (some?) Protobuf symbols (and our headers don't expose Protobuf definitions), but still registers the definitions in Flight.proto at runtime. Hence, an application that also tries to include and use Flight.proto will run into a runtime conflict. But excluding the application's generated code for Flight.proto leads to a link-time error when some symbols can't be found.
> We should consider exposing the Protobuf header/symbols from Flight so an application can mix and match. As with some of the other gRPC customization hooks exposed, we should make it clear that this may compromise future compatibility, that you will need to compile & link in a particular manner, and that Flight still isn't declared stable.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)