Registry /
observability / openlineage-integration-common
Install & Compatibility
Where this runs
tested against v1.52.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.95 runs
build_error
glibcpy 3.10–3.95 runs
installs and imports cleanly · install 3.5s · import 1.068s · 39MB
37MB installed
● package 37MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
DbTableSchema
✓ from openlineage.common.models import DbTableSchema
A common model for representing database table schemas.
SQLStatement
✓ from openlineage.common.provider import SQLStatement
Used for parsing and representing SQL statements within integrations.
get_common_config
✓ from openlineage.common.config import get_common_config
Utility to retrieve common OpenLineage configuration.
Source
✓ from openlineage.common.models import Source
Model for representing data sources.
This quickstart demonstrates how to use fundamental data models like `DbTableSchema`, `Source`, and `SQLStatement` provided by `openlineage-integration-common`. These models are essential building blocks when developing custom OpenLineage integrations or working with parsed metadata.
from openlineage.common.models import DbTableSchema, Source
from openlineage.common.provider import SQLStatement
# Example: Defining a database table schema
db_table = DbTableSchema(
schema='public',
table='my_table',
fields=[
{'name': 'id', 'type': 'int'},
{'name': 'name', 'type': 'string'}
]
)
print(f"Defined DB Table: {db_table.json(indent=2)}")
# Example: Defining a data source
my_source = Source(scheme='postgresql', authority='localhost:5432', connection_url='jdbc:postgresql://localhost:5432/mydb')
print(f"Defined Source: {my_source.json(indent=2)}")
# Example: Representing a SQL statement (without actual parsing logic)
sql_statement = SQLStatement(query='SELECT * FROM public.my_table')
print(f"SQL Statement: {sql_statement.json(indent=2)}")
Errors
Common errors & fixes
ModuleNotFoundError: No module named 'openlineage.common'
The `openlineage-integration-common` package is not installed in the Python environment, or a module from it is being imported incorrectly or from a location not on the Python path.
fixEnsure the package is installed: `pip install openlineage-integration-common`
AttributeError: 'NoneType' object has no attribute 'host'
This error typically occurs within an OpenLineage Airflow extractor when it attempts to access connection details (like host or port) from an Airflow connection object that is `None` or not properly resolved, often because connection information is stored in a secrets backend that the extractor cannot access.
fixVerify that Airflow connections are correctly configured and accessible to the OpenLineage extractor. This might involve configuring Airflow's secrets backend or ensuring connection details are explicitly provided if the extractor cannot resolve them automatically.
ValueError: OpenLineage is missing configuration, please refer to the OL setup docs.
The OpenLineage client or an integration (like the Airflow provider) cannot find essential configuration parameters, such as the OpenLineage backend URL (`OPENLINEAGE_URL`) or namespace (`OPENLINEAGE_NAMESPACE`), preventing it from emitting events.
fixSet the required environment variables (e.g., `OPENLINEAGE_URL=http://localhost:5000 OPENLINEAGE_NAMESPACE=default`) or provide a valid `openlineage.yml` configuration file in a discoverable location.
The Airflow Scheduler and Airflow Triggerer are failing to load the openlineage plugin with Custom extractors
Airflow's scheduler or triggerer processes are unable to correctly import or load custom OpenLineage extractors. This is often due to an incorrect path specified in the `OPENLINEAGE_EXTRACTORS` environment variable, or issues like circular imports within the custom extractor code that prevent successful loading.
fixVerify that the `OPENLINEAGE_EXTRACTORS` environment variable points to a correct and importable path from the Airflow worker's Python environment. Additionally, ensure custom extractor code avoids top-level Airflow imports by placing them within methods or guarding them with `typing.TYPE_CHECKING` to prevent circular dependencies.
Upgrade
Version history
1.52.0latest on PyPI · released Jul 23, 2026
Audit
Dependencies
pydanticrequiredUsed for defining data models and schema validation.
PyYAMLrequiredUsed for YAML configuration parsing.