Future of this crate and ADBC

[aljazerzen]

ADBC has recently updated their Rust API. It is quite similar to the ADBC C API, so it is would be possible to export a Rust ADBC driver as a C library to be used from any language using FFI.

The downside is that it is "low-level" and easy to misuse (i.e. by not setting SQL queries on a statement, by passing-in incorrectly formatted options, by not closing a statement but instead just dropping it). Such misuse would lead to run-time errors or undefined behavior.

This API is therefore "unsafe" and not suitable for general use in rust ecosystem. Instead, I suggest we create a high-level wrapper API that would be very hard or impossible to misuse but would use the "unsafe" API internally.

This way, it would also be possible to use non-Rust ADBC drivers from Rust via FFI.

---

Now, regarding this crate, I plan to:

• use connector_arrow::api as a base to define the high-level ADBC API,
• convert the connectors in the crate to implement the "unsafe" ADBC API.

(writing this, I realize we need a good name for the high-level ADBC API)

[tripokey]

This crate gives the application direct support for interacting with databases without having to manage separately installed drivers. Will this still be supported?

[aljazerzen]

separately installed drivers

What do you mean here?

With how I see now, rust applications would add dependency to:

• the high-level ADBC crate, which would also depend on the low-level ADBC API,
• the connectors currently implemented in connector_arrow,
  ... which would then provide the high-level ADBC API using Rust postgres crate, for example. It would not require you to have the pq library installed on your machine (or any other non-cargo library).

[tripokey]

From https://arrow.apache.org/docs/format/ADBC.html#example-use-cases

If the application wishes to work with multiple databases, it would link against the ADBC driver manager, and specify the desired driver at runtime. The driver manager would pass on API calls to the correct driver, which handles the request.

My interpretation of the above text is that ADBC functions similar to ODBC where you are required to have ODBC drivers installed on your system for each database that you want to interact with (at least if you want to interact with multiple different database types).

Currently this crates does not require any external driver to be present and the application can interact with multiple different database types without the end user having to manage external ADBC drivers.

[aljazerzen]

Oh, yes - I believe that quote talks about applications using the C ADBC API, which does not allow specifying multiple drivers in application code, so they use the driver_manager as the workaround.

All of that would not be necessary when using Rust ADBC API, which is defining traits that can be implemented and imported multiple times in your code.

[tripokey]

Then my question is resolved 🙂

Thanks for the quick replies 👍