Ahjo

Latest version: v3.10.1

Safety actively analyzes 690691 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 7

65.5.1

Build system for Ahjo depends on setuptools which has a ReDoS vulnerability CVE-2022-40897 in versions prior to 65.5.1. In this version, setuptools requirement version was updated to 65.5.1.

7.0

Added support for cx_Freeze 7.0.

Bug fix
`ahjo-upgrade` now returns exit status 0 if database is already up to date.

3.10.1

Python 3.13 support
Added Python 3.13 support (excluding MSI installation).

Updated version requirements
Updated the following packages in setup.cfg:

- `alembic >= 1.9, < 1.15`
- `networkx >= 3.3, < 3.5`
- `pyodbc >= 5.0, < 5.3`
- `azure-identity >= 1.16.1, < 1.20`

Regression fix: deploy_files with functions file sort
The optimization of `deploy_sqlfiles` function introduced in version 3.10.0 caused a regression in a situation where function files are sorted based on dependencies. This was caused by an incorrect regex pattern used to find dependencies in function files, which can lead to incorrect sorting of function files.

In this version, the regex pattern is fixed. However, the `deploy_sqlfiles` optimization is now disabled by default until the feature is fully tested and verified. The optimization can be enabled by setting the `sort_files` parameter to `True` when calling the function.

Regression fix: Known args are not backwards compatible
Previous version of ahjo added support for passing custom command-line flags to actions. This changed the behavior of old known arguments, mainly the `--files` and `--object_type` arguments. This version of ahjo reverts the behavior of these arguments to the previous state.

3.10.0

Reduce time complexity of deploy sql file loop
Ahjo deploy action was slow in certain scenarios. This was due the fact that the sql_file_loop function had a time complexity of O(n^2) where n is the number of files to be deployed (since max_loop was set to n when calling the function). Usually this was not a problem, but when files were dependent on each other (e.g. a view is created in one file and used in another) or errors occured during deployment, the function loops through the files multiple times. This has caused the deploy action to freeze for very long periods of time in some cases (so long that the user thinks the action has failed and cancels it).

The time complexity was reduced to O(n) by parsing the SQL files to find dependencies between them and deploying them in topological order.

New master actions for deploying database roles and permissions
Added new master actions for creating database roles, granting database permissions and creating database users. The actions are `create-db-roles`, `grant-db-permissions`, `create-db-users` and `add-users-to-roles`. See the action descriptions for more information.

New master action for visualizing database object dependencies
Added new master action `plot-dependencies` for visualizing sql file dependencies. The action parses the SQL files in the project and creates a dependency graph of the database objects. The graph is plotted with plotly. Currently the action is not supported in MSI-installed Ahjo.

Enable having default metadata information for a column with a certain name
Added the possibility to define default metadata for columns. When updating database object properties, if a table/view has a column with a certain name, and a default value for the metadata for that column has been defined in `./docs/db_objects/columns_default.json`, that value is used, unless there is a row for that specific table's column in `./docs/db_objects/columns.json`.

New flag for `ahjo-scan` command to add found scan results to ignore file
Added a new flag `--add-results-to-ignore` to `ahjo-scan` command. The flag can be used to add all found scan results to the ignore file. If the found scan results already exist in the ignore file, they are not added again.

Add support for passing custom command-line flags to actions
Added a new method `get_cli_arg` to `Context` class. The method can be used to access custom command-line arguments and their values in actions.
For example, to pass a custom boolean flag `--example-flag` to action `example-action`, use the following command:
bash
ahjo example-action <config> --example-flag

In the action, the values of the custom argument can be accessed from the context object:
python
example_flag = context.get_cli_arg("example-flag") Returns True if the flag is passed


Fine adjustments for printing test results
Fine-tuned the printing of database test results to console. Removed unnecessary information from the printed results and added a new line which summarizes how many tests passed.

Improve error handling in ahjo-upgrade
Improved and simplified the `ahjo-upgrade` operation by using a dependency graph to determine the order versions to be deployed. This change also fixed a bug where an incorrect error message was raised when some versions were missing in upgrade_actions file.

Show server & db name in ahjo-upgrade confirmation message
Now the confirmation message in `ahjo-upgrade` shows the target server and database name.

Updated version requirements
- Removed Python 3.11 support
- Added support for cx-freeze 7.2 and azure-identity 1.18.0
- Added new dependencies: networkx, plotly

Improvements to pipelines, tests and MSI build
- Optimized release pipeline
- Updated ODBC Driver 17 to 18 in pytests
- Fixed an incorrect MSI name in UAC prompt

3.9.4

Fix bug in optional pyodbc import
Pyodbc is not installed by default and is not required for all databases. Ahjo tries to import pyodbc and should continue without it if the import fails. However, the exception was not caught correctly which caused the program to crash in a situation where ahjo was installed without pyodbc. This has been fixed.

Update dependencies
Updated version requirements:
- `lark >= 1.1, < 1.3`

3.9.3

Regression bug fix
Fixed a bug which caused `ahjo init` action to fail when `connect_resiliently` was set to `true`.

Database name verification
Added a new setting `target_database_protected` to ask user to verify database name before running actions. The setting is set to `false` by default.

setuptools_scm parameter update
setuptools_scm setting `write_to` under `tools.setuptools_scm` is deprecated. The setting is now replaced with `version_file`.

Page 1 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.