Databricks-labs-lsql

* Let page name adhere to naming restrictions ([370](https://github.com/databrickslabs/lsql/issues/370)). In this release, a new method `_clean_resource_name` has been introduced to modify resource names according to the updated naming convention, allowing only alphanumeric characters, hyphens, and underscores. The `as_lakeview` method in the `BaseHandler` class now uses this new method to ensure the `Page` class name adheres to the new restrictions. Furthermore, test files for dashboards have been updated to reflect the change, with a new test function `test_dashboard_metadata_as_lakeview_cleans_page_name` verifying that page names are free of special characters, and an existing test function modified to handle invalid dashboard YAML files. These changes improve consistency, reliability, and adherence to best practices in dashboard naming within the project.

* remove duplicate changelog entry ([366](https://github.com/databrickslabs/lsql/issues/366)). In this update, we've improved resource name validation in the `ucx` project, first introduced in version 0.14.2. The validation now restricts resource names to alphanumeric characters, hyphens, and underscores, addressing usability issues and preventing problems caused by special characters. A new internal method, `_is_valid_resource_name`, checks if a name is valid according to the defined pattern. The `TileMetadata` class has been updated to ensure its `id` attribute follows the new validation rules, and `Tile`, `Section`, and `Dashboard` classes now call the `validate` method of the `TileMetadata` instance if it exists. These changes promote consistency and correctness in dashboard resources, simplifying management and interaction for users. As a part of this commit, we also removed a duplicate changelog entry related to this feature that was previously present in version 0.15.0.

* Validate resource names ([357](https://github.com/databrickslabs/lsql/issues/357)). The recent change in the `ucx` project enhances resource name validation to adhere to a new naming convention, restricting names to alphanumeric characters, hyphens, and underscores. A new method, `_is_valid_resource_name(name: str) -> bool`, is introduced for validating resource names, and the `TileMetadata` class has been updated with a `__post_init__` method and a `validate` method for validation purposes. The `Tile` and `FilterTile` classes also receive a `validate` method to raise `ValueError` for invalid tiles and metadata issues. This commit introduces new tests for validating tile IDs, tile metadata, and filter specs while improving error messages for better user understanding. It also raises `ValueError` for tiles with empty content, tiles with names containing spaces, and filter tiles with invalid widget types, ensuring stricter validation for dashboard metadata and tile metadata in the `ucx` project.

* Validate resource names ([357](https://github.com/databrickslabs/lsql/issues/357)). This pull request introduces a validation feature to the `ucx` project for resource names, specifically for dashboard tile IDs. The new naming convention restricts resource names to alphanumeric characters, hyphens, and underscores, enhancing usability and reducing potential issues caused by special characters. A new method, `_is_valid_resource_name`, is implemented to check if a name is valid based on the defined pattern. The `TileMetadata` class is updated to ensure its `id` attribute adheres to the new validation rules, and a `validate` method is added to raise a `ValueError` if the tile metadata is invalid. This method checks if the `id` attribute is not empty and if it is a valid resource name. Additionally, the `validate` method is updated in the `Tile`, `Section`, and `Dashboard` classes to call the `validate` method of the `TileMetadata` instance, if it exists. The pull request also includes tests for the new validation functionality, ensuring that tile IDs cannot be empty, must contain only alphanumeric characters, hyphens, and underscores, and that the `validate` method detects duplicate query IDs and widget IDs. This validation helps maintain consistency and correctness in dashboard resources, making it easier for users to manage and interact with their dashboards.
* Updated runner ([360](https://github.com/databrickslabs/lsql/issues/360)). In this release, we have updated the GitHub Actions workflow for releasing the project to utilize a protected runner group with the label `linux-ubuntu-latest` in the `publish` job's `runs-on` field. This change enhances control and security over the execution environment, as the protected runner group, `databrickslabs-protected-runner-group`, ensures that only specified runners that meet specific criteria are allowed to execute jobs. The `linux-ubuntu-latest` label specifies the desired runner configuration. Furthermore, the workflow now utilizes an environment named `release` and retains the existing permissions configuration for authenticating to PyPI via OIDC and signing release artifacts with `sigstore-python`. This upgrade to the execution environment preserves essential authentication and security features, providing improved reliability, maintainability, and security for the release process while ensuring continued compatibility and security for publishing activities.
* Explicitly install Python 3.12 before running fmt in CI ([358](https://github.com/databrickslabs/lsql/issues/358)). In this release, we have made significant enhancements to our open-source library aimed at improving reliability, consistency, and usability for software engineers. A new step installing Python 3.12 explicitly before executing the formatting process in the CI system has been implemented, ensuring compatibility and consistency with the chosen Python version. The 'backends.py' file's `save_table` function syntax has been updated for better code readability and maintainability, addressing potential SQL injection issues. The 'model.py' file has undergone refactoring, updating `KeyError` exceptions to f-strings for improved consistency and readability, and the 'polymorphism.py' file has been improved with new functions and refined error messages for better debugging and understanding of type assignment issues. Lastly, the 'structs.py' file in the 'databricks/labs/lsql' package has received updates to ensure consistent Python version usage, improved error messages, and better SQL type inference from Python types, enhancing the overall development experience for adopting engineers.

* Changes to work with Databricks SDK `v0.38.0` ([350](https://github.com/databrickslabs/lsql/issues/350)). In this release, we have upgraded the Databricks SDK to version 0.38.0 from version 0.37.0 to ensure compatibility with the latest SDK and address several issues. The update includes changes to make the code compatible with the new SDK version, removing the need for `.as_dict()` method calls when creating or updating dashboards and utilizing a `sdk_dashboard` variable for interacting with the Databricks workspace. We also updated the dependencies to "databricks-labs-blueprint[yaml]" package version greater than or equal to 0.4.2 and `sqlglot` package version greater than or equal to 22.3.1. The `test_core.py` file has been updated to address multiple issues ([#349](https://github.com/databrickslabs/lsql/issues/349) to [#332](https://github.com/databrickslabs/lsql/issues/332)) related to the Databricks SDK and the `test_dashboards.py` file has been revised to work with the new SDK version. These changes improve integration with Databricks' lakeview dashboards, simplify the code, and ensure compatibility with the latest SDK version, resolving issues [#349](https://github.com/databrickslabs/lsql/issues/349) to [#332](https://github.com/databrickslabs/lsql/issues/332).
* Specify the minimum required version of `databricks-sdk` as 0.37.0 ([331](https://github.com/databrickslabs/lsql/issues/331)). In this release, we have updated the minimum required version of the `databricks-sdk` package to 0.37.0 from 0.29.0 in the `pyproject.toml` file to ensure compatibility with the latest version. This change was made necessary due to updates made in issue [#320](https://github.com/databrickslabs/lsql/issues/320). To accommodate any patch release of `databricks-sdk` with a major and minor version of 0.37, we have updated the dependency constraint to use the `~=` operator, resolving issue [#330](https://github.com/databrickslabs/lsql/issues/330). These changes are intended to enhance the compatibility and stability of our software.

* Added nightly tests run at 4:45am UTC ([318](https://github.com/databrickslabs/lsql/issues/318)). A new nightly workflow has been added to the codebase, designed to automate a series of jobs every day at 4:45am UTC on the `larger` environment. The workflow includes permissions for writing id-tokens, accessing issues, reading contents and pull-requests. It checks out the code with a full fetch-depth, installs Python 3.10, and uses hatch 1.9.4. The key step in this workflow is the execution of nightly tests using the databrickslabs/sandbox/acceptance action, which creates issues if necessary. The workflow utilizes several secrets, including VAULT_URI, GITHUB_TOKEN, ARM_CLIENT_ID, and ARM_TENANT_ID, and sets the TEST_NIGHTLY environment variable to true. Additionally, the workflow is part of a concurrency group called "single-acceptance-job-per-repo", ensuring that only one acceptance job runs at a time per repository.
* Bump codecov/codecov-action from 4 to 5 ([319](https://github.com/databrickslabs/lsql/issues/319)). In this version update, the Codecov GitHub Action has been upgraded from 4 to 5, bringing improved functionality and new features. This new version utilizes the Codecov Wrapper to encapsulate the CLI, enabling faster updates. Additionally, an opt-out feature has been introduced for tokens in public repositories, allowing contributors and other members to upload coverage reports without requiring access to the Codecov token. The upgrade also includes changes to the arguments: `file` is now deprecated and replaced with `files`, and `plugin` is deprecated and replaced with `plugins`. New arguments have been added, including `binary`, `gcov_args`, `gcov_executable`, `gcov_ignore`, `gcov_include`, `report_type`, `skip_validation`, and `swift_project`. Comprehensive documentation on these changes can be found in the release notes and changelog.
* Fixed `RuntimeBackend` exception handling ([328](https://github.com/databrickslabs/lsql/issues/328)). In this release, we have made significant improvements to the exception handling in the `RuntimeBackend` component, addressing issues reported in tickets [#328](https://github.com/databrickslabs/lsql/issues/328), [#327](https://github.com/databrickslabs/lsql/issues/327), [#326](https://github.com/databrickslabs/lsql/issues/326), and [#325](https://github.com/databrickslabs/lsql/issues/325). We have updated the `execute` and `fetch` methods to handle exceptions more gracefully and changed exception handling from catching `Exception` to catching `BaseException` for more comprehensive error handling. Additionally, we have updated the `pyproject.toml` file to use a newer version of the `databricks-labs-pytester` package (0.2.1 to 0.5.0) which may have contributed to the resolution of these issues. Furthermore, the `test_backends.py` file has been updated to improve the readability and user-friendliness of the test output for the functions testing if a `NotFound`, `BadRequest`, or `Unknown` exception is raised when executing and fetching statements. The `test_runtime_backend_use_statements` function has also been updated to print `PASSED` or `FAILED` instead of returning those values. These changes enhance the robustness of the exception handling mechanism in the `RuntimeBackend` class and update related unit tests.

Dependency updates:

* Bump codecov/codecov-action from 4 to 5 ([319](https://github.com/databrickslabs/lsql/pull/319)).