airflow.hooks.base¶
Base class for all hooks.
Module Contents¶
Classes¶
Abstract base class for hooks. |
|
Interface that providers can implement to be discovered by ProvidersManager. |
Attributes¶
- class airflow.hooks.base.BaseHook(logger_name=None)[source]¶
Bases:
airflow.utils.log.logging_mixin.LoggingMixinAbstract base class for hooks.
Hooks are meant as an interface to interact with external systems. MySqlHook, HiveHook, PigHook return object that can handle the connection and interaction to specific instances of these systems, and expose consistent methods to interact with them.
- Parameters
logger_name (str | None) – Name of the logger used by the Hook to emit logs. If set to None (default), the logger name will fall back to airflow.task.hooks.{class.__module__}.{class.__name__} (e.g. DbApiHook will have airflow.task.hooks.airflow.providers.common.sql.hooks.sql.DbApiHook as logger).
- classmethod get_connections(conn_id)[source]¶
Get all connections as an iterable, given the connection id.
- Parameters
conn_id (str) – connection id
- Returns
array of connections
- Return type
- classmethod get_connection(conn_id)[source]¶
Get connection, given connection id.
- Parameters
conn_id (str) – connection id
- Returns
connection
- Return type
- class airflow.hooks.base.DiscoverableHook[source]¶
Bases:
airflow.typing_compat.ProtocolInterface that providers can implement to be discovered by ProvidersManager.
It is not used by any of the Hooks, but simply methods and class fields described here are implemented by those Hooks. Each method is optional – only implement the ones you need.
The conn_name_attr, default_conn_name, conn_type should be implemented by those Hooks that want to be automatically mapped from the connection_type -> Hook when get_hook method is called with connection_type.
Additionally hook_name should be set when you want the hook to have a custom name in the UI selection Name. If not specified, conn_name will be used.
The “get_ui_field_behaviour” and “get_connection_form_widgets” are optional - override them if you want to customize the Connection Form screen. You can add extra widgets to parse your extra fields via the get_connection_form_widgets method as well as hide or relabel the fields or pre-fill them with placeholders via get_ui_field_behaviour method.
Note that the “get_ui_field_behaviour” and “get_connection_form_widgets” need to be set by each class in the class hierarchy in order to apply widget customizations.
For example, even if you want to use the fields from your parent class, you must explicitly have a method on your class:
@classmethod def get_ui_field_behaviour(cls): return super().get_ui_field_behaviour()
You also need to add the Hook class name to list ‘hook_class_names’ in provider.yaml in case you build an internal provider or to return it in dictionary returned by provider_info entrypoint in the package you prepare.
You can see some examples in airflow/providers/jdbc/hooks/jdbc.py.
- static get_connection_form_widgets()[source]¶
Return dictionary of widgets to be added for the hook to handle extra values.
If you have class hierarchy, usually the widgets needed by your class are already added by the base class, so there is no need to implement this method. It might actually result in warning in the logs if you try to add widgets that have already been added by the base class.
Note that values of Dict should be of wtforms.Field type. It’s not added here for the efficiency of imports.
- static get_ui_field_behaviour()[source]¶
Attributes of the UI field.
Returns dictionary describing customizations to implement in javascript handling the connection form. Should be compliant with airflow/customized_form_field_behaviours.schema.json’
If you change conn_type in a derived class, you should also implement this method and return field customizations appropriate to your Hook. This is because the child hook will have usually different conn_type and the customizations are per connection type.
See also
ComputeSSHas an example