wjones127 commented on code in PR #428: URL: https://github.com/apache/arrow-adbc/pull/428#discussion_r1100717519
########## adbc.h: ########## @@ -1183,7 +1204,11 @@ AdbcStatusCode AdbcStatementExecutePartitions(struct AdbcStatement* statement, /// driver. /// /// Although drivers may choose any name for this function, the -/// recommended name is "AdbcDriverInit". +/// recommended name is "AdbcDriverInit". If you use the recommended +/// name, then driver managers will be able to automatically find +/// the entrypoint function. Drivers may also expose the same function +/// under a unique symbol so that multiple drivers can be statically +/// linked into a single binary without any conflicts. Review Comment: That's basically what I've done. There's a concrete struct `FFI_AdbcDriver` that represents the struct as defined in the ADBC header. Then there's `AdbcDriver`, which is the safe wrapper around `FFI_AdbcDriver`. I might be conflating some things when I say "driver manager". I'm basically calling the `AdbcDriver` struct a driver manager because it has a function `AdbcDriver::load()` which initializes a new instance from a shared library or init function. But the API I've exposed so far in Rust always calls the function pointers on some `FFI_AdbcDriver`, and never tries to access any of the top-level `Adbc*` functions. I could add support for calling them maybe, but seems easier just to expose the `AdbcDriver::load()` path and tell people to always use that. Or if they really want to just call the `AdbcDriverInit` function themselves to create a `FFI_AdbcDriver` struct. -- 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]
