If you can include the full failed build log that may help. I did
confirm that I can build ninja-debug-gandiva though I had to install
considerably more conda dependencies than the ones you listed (e.g.
boost, gmock, gflags, etc). Presumably you have these in your base
conda environment or instal
I may indeed be confused. I haven’t spent a lot of time looking at FlightSQL’s
capabilities. Apologies for that.
My main point was to keep protocols, language-specific APIs (e.g. ODBC, JDBC),
frameworks (e.g. Gavin’s proposed data frames system) decoupled from one
another, and build on existing
Forking this thread to a new topic, it has strayed quite a bit from the
original discussion I think which was for server side Java implementations.
On Tue, Mar 15, 2022 at 9:14 AM James Duong
wrote:
> I could also see extensions to ODBC/JDBC being a point of confusion for app
> developers too.
I could also see extensions to ODBC/JDBC being a point of confusion for app
developers too.
For example, if we were to add hooks in the JDBC driver to report endpoints
so that
applications can call getStream() directly, what would happen if the user
started getting
a stream then went back and trie
In general, I have problems with attempting to expose other extensions
through existing standards such as ODBC/JDBC. What it feels like we're
saying is: use the standard so you don't have to change any code, except
for this part where you must write custom code to take advantage of the
non-standard
Aren't we getting a few things mixed up here?
1) As Micah says, the original proposal is about adapting Java types to Arrow.
This can be used independently of Flight SQL. I don't think this was being
pitched as a standard itself unless I'm mistaken?
2) Flight SQL the protocol, which _is_ a lan
