This page covers entity resolution, cross-database lineage, stored procedure and view lineage, parallel processing, publishing, dialect mapping, and configuration. For the pipeline overview, SQL parsing, and graph analysis, see Lineage Ingestion.
Before publishing, table names from SQL must be resolved to OpenMetadata entities:
search_table_entities(service_name, database, schema, table) 1. Search Elasticsearch (fast) for table FQN 2. If not found, try API search (reliable) 3. If schema not found, retry without schema qualifier 4. Cache results (1,000-entry LRU cache)
This resolution step is critical — lineage can only be created between entities that exist in the catalog.
# Query references tables from multiple services:INSERT INTO warehouse.analytics.summarySELECT * FROM production.sales.orders# Resolution searches across multiple services:search_table_entities( service_names=["warehouse_service", "production_service"], ...)
Configured via crossDatabaseServiceNames in the workflow config.
add_lineage(request, check_patch=False) 1. Check if edge already exists 2. If exists: merge column lineage (union of old + new columns) 3. If new: create edge 4. Cache the result
For views, write_override_lineage() replaces existing lineage entirely (since view definitions can change).
All paths above are relative to ingestion/src/metadata/ingestion/. For example, lineage/parser.py means ingestion/src/metadata/ingestion/lineage/parser.py.