esodan commented on issue #1280:
URL: https://github.com/apache/arrow-adbc/issues/1280#issuecomment-1820274429
> How about `GADBCArrow`?
>
> I don't want to use the `#if` approach. `libadbc-arrow-glib` should depend
on `libadbc-glib` and `libarrow-glib`. If we use the `#if` approach, users use
`libadbc-arrow-glib` as an alternative of `libadbc-glib`, right? I don't want
to put same symbols to both of `libadbc-glib` and `libadbc-arrow-glib`.
I see.
On using `#if`, yes if users want a fully introspectable API they should use
`libadbc-arrow-glib`, with the same namespace and objects as for
`libadbc-glib`. Lets consider the following Code (in Vala for easy reading):
This is how `libadbc-arrow-glib` should be used:
```vala
var statement = new GADBC.Statement (connection);
string sql = "SELECT sqlite_version() AS version";
statement.set_sql_query (sql);
int64 n_rows_affected = 0;
GArrow.RecordBatchReader reader = statement.execute_stream (out
n_rows_affected);
var table = reader.read_all ();
stdout.printf ("Result:\n%s", table.to_string ());
```
Above code is introspectable, but `libadbc-arrow-glib` have same symbols and
namespace than `libadbc-glib`, they share same source code and `#if` is used to
add code when compiling for `libadbc-arrow-glib` to add `GArrow` API symbols.
This is how `libadbc-glib` should be used:
```vala
var statement = new GADBC.Statement (connection);
string sql = "SELECT sqlite_version() AS version";
statement.set_sql_query (sql);
void *c_abi_array_stream = null;
int64 n_rows_affected;
statement.execute (true, out c_abi_array_stream, out n_rows_affected);
var reader = GArrow.RecordBatchReader.import (c_abi_array_stream);
var table = reader.read_all ();
stdout.printf ("Result:\n%s", table.to_string ());
```
Above code works currently, but is not completely introspectable.
This is how `libadbc-glib` and `libadbc-arrow-glib` (dependant) should be
used:
```vala
var statement = new GADBC.Statement (connection);
string sql = "SELECT sqlite_version() AS version";
statement.set_sql_query (sql);
var stm = GADBCArrow.Statement (statement);
GArrow.RecordBatchReader reader = stm.execute (true, out n_rows_affected);
var table = reader.read_all ();
stdout.printf ("Result:\n%s", table.to_string ());
```
In above code we use `GADBCArrow` name space, creating a new set of objects
that use internally objects from `GADBC`, so `var stm = GADBCArrow.Statement
(statement)` is required to add new API. I think, this approach is harder to
use.
There is a way, where we wrap all API from `GADBC` into new objects
definitions in `GADBCArrow`, so when calling a method in `GADBCArrow` for an
object, internally calls the method from `GADBC` library. But means a lot of
work and when `GADBC` is added the corresponding object should be added to
`GADBCArrow` too.
This is how `libadbc-glib` and `libadbc-arrow-glib` (dependant and
wrapping) should be used:
```vala
var statement = new GADBCArrow.Statement (connection);
string sql = "SELECT sqlite_version() AS version";
statement.set_sql_query (sql);
GArrow.RecordBatchReader reader = statement.execute (true, out
n_rows_affected);
var table = reader.read_all ();
stdout.printf ("Result:\n%s", table.to_string ());
```
Above code all objects including `connection` are objects in `GADBCArrow`
that wraps objects from `GADBC` and their API.
I consider the wrapping solution is harder to implement and maintain; while
the use of `#if` solution allows to share source code and add just the API
using `GArrow` symbols when creating the `libadbc-arrow-glib` library.
`libadbc-arrow-glib` doesn't depend on `libadbc-glib` they are alternatives
each other is up to the user to select one or the other depending on what
programming language is using.
Consider that `libadbc-arrow-glib` will be the facto library for languages
using GObject Introspection to access `ADBC`, because that library will be
fully introspectable and easy to use on Python, JS and other languages.
Hope all above convince you to create a C API far from GLIb/GObject and
allow that `GADBC` is modified to provide a fully introspectable API for the
future. Yes, that is an API break, but may be necessary in order to make `ADBC`
available for more languages using GObject Introspection.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
