feat(csharp/src/Drivers/Databricks): Default catalog + schema support

[toddmeng-db]

Allows users to specify an optional default catalog and default schema that will take affect throughout the session.

Includes tests that verifies basic behavior. To test, include in the DATABRICKS_TEST_CONFIG_FILE environment variable:

  "catalog": "system",
  "db_schema": "access",

NOTE: using Namespace to set catalogs is only in DBR 8.4+

[jadewang-db]

use string.IsNullOrWhitespace

[CurtHagenlocher]

Thanks! New properties should be described in readme.md. One thing that I find non-obvious is the relationship between these properties and the standard ADBC properties adbc.connection.catalog and adbc.connection.db_schema. It looks like those properties aren't supported by the driver at all, whereas these Databricks-specific properties are only supported when creating a new session. Can the current catalog or schema be changed after the session is established? And at that point the initial values don't matter any more?

I think some clarity is required here in the docs even if the code doesn't change.

[CurtHagenlocher]

nit: namespace ordering

[CurtHagenlocher]

With InternalsVisibleToAttribute and an internal property, it shouldn't be necessary to use Reflection to get at this property value.

[CurtHagenlocher]

I think my expectation as an ADBC user would be that if I set adbc.connection.catalog and adbc.connection.db_schema before the connection is opened, that it would use those values to populate the initial namespace. And if I set them after the connection was opened, I'd get whatever it takes to update the session value (e.g. USE CATALOG catalog_name).

[toddmeng-db]

I think my expectation as an ADBC user would be that if I set adbc.connection.catalog and adbc.connection.db_schema before the connection is opened, that it would use those values to populate the initial namespace.

Makes sense - sorry I didn't even realize that these parameters were already there 😅

[eric-wang-1990]

I think my expectation as an ADBC user would be that if I set adbc.connection.catalog and adbc.connection.db_schema before the connection is opened, that it would use those values to populate the initial namespace. And if I set them after the connection was opened, I'd get whatever it takes to update the session value (e.g. USE CATALOG catalog_name).

This initial catalog/schema should only be used when opening session, in powerbi when user signed in and pick the initial catalog/schema there is no way to change that unless user make brand new connection.
The way we setting those parameter is in OpenSession, which is considered faster than a explictly SET catalog=x command. I think until we receive real needs of modifying the initial catalog/schema after connection is established, we can assume it only works for when connection is established.

[CurtHagenlocher]

This initial catalog/schema should only be used when opening session, in powerbi when user signed in and pick the initial catalog/schema there is no way to change that unless user make brand new connection. The way we setting those parameter is in OpenSession, which is considered faster than a explictly SET catalog=x command. I think until we receive real needs of modifying the initial catalog/schema after connection is established, we can assume it only works for when connection is established.

Notwithstanding that (at least in principle) this driver should be useful outside of a narrow Power BI context, Power BI does make use of the ability to set the current catalog; it's a prerequisite for being able to use Value.NativeQuery with pooled connections.