Ahjo

Support for adding/dropping SQL files listed in --files argument
Added new master actions: `deploy-files` and `drop-files`.

Pin all dependencies to their exact versions
Install only versions that do not have any known vulnerabilities or compatibility problems.

Update git version in data action and create a separate action for it
In previous versions, the git version was updated to the database only as part of the deploy action.
In this version, git version is updated as part of the data action, since sometimes data is updated without running deploy.
In addition, a new master action `update_git_version` has been added so it can run also in other situations when needed.

Change execution order in deploy-action
In previous versions, if you had metadata descriptions defined for git_version-table, they were not updated when the database was built for the first time. This is because git_version table is created after the metadata update.
Solution was to change execution order in deploy-action:

1. update_git_version
2. update_db_object_properties

Bug fix: Tabs in SQL files are converted to spaces in function execute_from_file
Override default behavior of converting tabs to spaces before parsing input string.

Bug fix: Ahjo fails to split sql code to batches if input contains lower-case batch separators
Change mssql batch separator to case insensitive.

Bug fix: Ahjo fails to split sql code to batches if GO statement is indented
Allow space/tab indentations to GO commands

Bug fix: Ahjo fails to split sql code to batches when sql code contains GOTO statement
Allow GOTO statements to be used in sql files.

Bug fix: execute_from_file interprets colon+letters as parameter placeholder
Escape colon characters in execute_from_file (when using mssql+pyodbc dialect).

Platform-specific dependencies
The dependencies of Ahjo have been split into common dependencies and platform-specific dependencies. Command `pip install ahjo` will install only the common dependencies. In order to use Ahjo with the database engine of your choice, install platform-specific dependencies using available tags. For example, if you use Ahjo with Microsoft SQL Server, use tag `mssql` to install required dependencies.

Common dependencies
- alembic
- commentjson
- pyparsing
- sqlalchemy

Platform-specific dependencies (and available platform tags)
- mssql
- pyodbc


this command installs Ahjo and common dependencies
pip install ahjo

this command installs Ahjo, common dependencies and mssql depenendecies (pyodbc)
pip install ahjo[mssql]


Support for three different Azure AD authentication methods
Added new (optional) variable `azure_authentication` to config.

Possible values:
- "ActiveDirectoryPassword" (Username and password)
- "ActiveDirectoryInteractive" (MFA - username given to Ahjo, password and single sign-on code are given interactively to driver)
- "ActiveDirectoryIntegrated" (Similar to windows authentication/trusted connection)

Notice, that Azure AD authentication is fully supported only by the latest ODBC Driver for SQL Server (ODBC Driver 17 for SQL Server).

Partially replace SQLCMD
To fully enable support for Azure AD authentication in Ahjo, SQLCMD had to be at least partially replaced. The problems with SQLCMD included:
- Every single time SQLCMD was called, a new connection and authentication to database was made
- When in use, MFA had to be executed for every single deployed object
- If you mistyped your password, deploy would spam your credentials to database n*n times, where n is the amount of deployed objects
- This sometimes resulted to user to be locked from database
- SQLCMD is a Microsoft SQL Server specific tool

In this version, SQLCMD has been partially replaced with a solution (`ahjo.database_utilities.sqla_utilities.execute_from_file`) that splits SQL stored in file into batches and executes the batches with SQL Alchemy. This solution solves the problems listed above.
- In `deploy_sqlfiles`, the loop logic is the same, but SQLCMD execution (`ahjo.database_utilities.sqlcmd.invoke_sqlcmd`) is replaced with `ahjo.database_utilities.sqla_utilities.execute_from_file`
- `sqlfiles.py`moved from `operations/tsql` to `operations/general`
- No significant effect to end-user, since all operations can be imported from `ahjo.operations`

Type hints
Added type hints to all modules.

Format bulk insert output
Print only two decimals for bulk insert duration.

Lock SQLAlchemy versions
Ahjo is compatible with SQLAlchemy versions >=1.3.0 and <1.4.0. Version 1.4.0 has some bugs that affect the functionality of Ahjo.

We'll start preparing for SQLAlchemy 2.0.

Initialize dummy file from Alembic
When initializing a new project, Ahjo creates a dummy file under `/alembic/versions`. This will make sure directory `/alembic/versions` is added to version control even though project has no Alembic migrations. It is a pain if this directory is lost, since Alembic actions require the existence of such directory.

Bug fix: Inform user if Alembic version table is empty
In previous versions, fetching Alembic version from empty Alembic version table caused Ahjo to crash. In this version, instead of crashing, Ahjo informs user that Alembic version table is empty and there are no deployed revisions.

Command listing available actions
With command `ahjo list` you can view all available actions and their descriptions.

Action name from function name
In older versions of Ahjo, action name had to be given as parameter to action decorator.

action(name='test', affects_database=False, dependencies=['deploy'])
def test_action(context):
print("Its working!")

In this version, if action name is not explicitly defined, the action will have the same name as the decorated function.
Underscones are interpret as hyphen. If the name of the decorated function is `test_action`, the action will be named `test-action`.

action(affects_database=False, dependencies=['deploy'])
def test(context):
print("Its working!")

Bug fix: Extended property name and value length when queried from database

Convert extended property names and values to VARCHAR(8000) when fetching them from database.