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 2022/06/15 20:34:00 UTC

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

     [ https://issues.apache.org/jira/browse/ARROW-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Li reassigned ARROW-14771:
--------------------------------

    Assignee: David Li

> [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
>            Assignee: David Li
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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.7#820007)