CurtHagenlocher commented on code in PR #4341: URL: https://github.com/apache/arrow-adbc/pull/4341#discussion_r3278335771
########## csharp/src/Apache.Arrow.Adbc/readme.md: ########## @@ -27,52 +27,87 @@ The `Apache.Arrow.Adbc.DriverManager` namespace provides a .NET implementation o ### Features - **Driver discovery**: search for ADBC drivers by name across configurable directories (environment variable, user-level, system-level). -- **TOML manifest loading**: locate drivers via `.toml` manifest files that specify the shared library path. +- **TOML driver manifests**: locate drivers via `.toml` manifest files that specify the shared library path per platform. - **Connection profiles**: load reusable connection configurations (driver + options) from `.toml` profile files. +- **Managed (.NET) drivers**: load .NET drivers via a scheme-prefixed `entrypoint` (`dotnet:` for .NET 5+, `netfx:` for .NET Framework 4.x). - **Custom profile providers**: plug in your own `IConnectionProfileProvider` implementation. -### TOML Manifest / Profile Format +### Driver Manifest Format -#### Connection Profile Example (Snowflake) +A *driver manifest* is a TOML file describing where a driver lives and how to load it. The format is shared across all ADBC driver-manager implementations and documented in `docs/source/format/driver_manifests.rst`. -For unmanaged drivers loaded from native shared libraries: +#### Native Driver Manifest Example (Snowflake) ```toml -profile_version = 1 -driver = "libadbc_driver_snowflake" +manifest_version = 1 + +name = "Snowflake" +version = "1.5.2" +publisher = "snowflake.com" + +[Driver] entrypoint = "AdbcDriverSnowflakeInit" +[Driver.shared] +windows_amd64 = "C:\\path\\to\\adbc_driver_snowflake.dll" +linux_amd64 = "/usr/local/lib/libadbc_driver_snowflake.so" +macos_arm64 = "/opt/homebrew/lib/libadbc_driver_snowflake.dylib" +``` + +#### Managed Driver Manifest Example (BigQuery) + +Managed .NET drivers use a scheme-prefixed `entrypoint`: + +- `dotnet:` for modern .NET (.NET 5 and later, including .NET 8 / .NET 10) +- `netfx:` for .NET Framework 4.x + +The host process rejects a manifest whose scheme doesn't match its runtime, so a `dotnet:` manifest on a .NET Framework process (or vice versa) fails with a clear error rather than mysteriously failing inside the assembly loader. Review Comment: @ianmcook, @davidhcoe, @esadek I've taken the liberty to amend the Driver Manager spec to accommodate drivers which are .NET assemblies and non-AOT compiled. This scheme could further be generalized to e.g. reference a .jar file or a Python-based implementation, if there ever were such a thing. Use of a scheme here is a backwards-compatible way to tell the driver manager how to consume the driver -- or perhaps that it is unable to. One could imagine (implausible as it likely is) that the C++ driver manager could see `dotnet:` and try to load the .NET runtime to load the driver. And of course, a naive examination of the entrypoint as written would fail to find the symbol in the library. -- 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]
