Skip to content
RelationalAI Docs

What's New in Version 0.9.10

Version 0.9.10 of the relationalai Python package is now available. This release includes enhanced Snowflake authentication options, secure token caching, improved warnings, and a bug fix for how transaction duration is reported in the CLI.

To upgrade, activate your virtual environment and run the following command:

Terminal window
pip install --upgrade relationalai

New Features and Enhancements

Section titled “New Features and Enhancements”

  • Introducing Direct Access: Direct Access sends Python client calls straight to the RelationalAI Native App’s secure ingress endpoint for lower latency and fewer moving parts. See Direct Access in the App Management guide for more information. The Configuration guide has also been updated with details on setting up Direct Access.

    There are three ways to authenticate Direct Access sessions in the Python client, each of which requires specific configuration settings in your raiconfig.toml profile as well as some admin setup in Snowflake:

    1. OAuth Authorization Code: Ideal for local development and testing. Browser login + local callback on localhost:8001. Tokens are cached in your system keyring (if available) so repeated runs usually won’t prompt you again.

      raiconfig.toml
      [profile.default]
      platform = "snowflake"
      use_direct_access = true
      authenticator = "oauth_authorization_code"
      oauth_client_id = "<OAUTH_CLIENT_ID>"
      oauth_redirect_uri = "<OAUTH_REDIRECT_URI>"  -- e.g. "http://localhost:8001/snowflake/oauth-redirect" (defined in the security integration)

      If the keyring is unavailable or insecure, the client warns you and falls back to prompting per run.

    2. Personal Access Token (PAT): Ideal for scripts & CI. Store the PAT in a file with restricted permissions:

      raiconfig.toml
      [profile.ci]
      platform = "snowflake"
      use_direct_access = true
      authenticator = "programmatic_access_token"
      token_file_path = "/secure/path/direct_access_token"

      If an unsupported authenticator is set with use_direct_access = true, the client disables Direct Access for that session and shows a clear warning.

    3. Key-Pair (JWT): Use an RSA private key—no password or long‑lived token needed:

      raiconfig.toml
      [profile.service]
      platform = "snowflake"
      use_direct_access = true
      authenticator = "snowflake_jwt"
      private_key_file = "/secure/path/rsa_key.p8"
      # private_key_file_pwd = "<password>"  # only if the key file is encrypted

  • The Python client now automatically selects the appropriate authenticator based on your configuration:

    • If you provide a private_key_file, the client uses key pair (JWT) authentication (snowflake_jwt).
    • If you provide a passcode, multi-factor authentication (username_password_mfa) is used automatically.
    • If neither is provided, the default Snowflake authenticator (snowflake) is used.
    • If you explicitly set the authenticator, that setting is preserved and not overridden.

    This enhancement streamlines Snowflake authentication setup, improves compatibility with enterprise security practices, and reduces configuration errors.

  • When importing tables from Snowflake, the Python client now detects and warns you about any columns with unsupported data types such as VARIANT, OBJECT, and other complex types. Instead of silently ignoring these columns, you’ll receive a clear warning listing the affected tables and columns, along with a link to documentation on supported column types. This helps you quickly identify which columns won’t be accessible in your semantic model and take action if needed. If many unsupported columns are found, only the first 10 are shown to keep the warning concise. To avoid missing data, review the warning and consider adjusting your Snowflake schema to use supported column types. For more details, see the Supported Column Types.

Bug Fixes

Section titled “Bug Fixes”
  • Fixed a bug in the RelationalAI CLI and Python client where transactions in terminal states (COMPLETED, ABORTED) showed durations that kept increasing over time. Now, the duration for finished transactions correctly reflects the time between creation and completion or abortion, remaining constant when viewed later. For running transactions, duration continues to update in real time. If a terminal transaction lacks a finish timestamp, its duration is shown as zero. This improvement ensures transaction durations are accurate and reliable, helping you better audit and understand transaction timelines. No action is needed—this fix is applied automatically.