Fixes #22916: Add chart-level lineage for Metabase connector

[Ryadlotfimahtal]

Describe your changes:

Fixes #22916

The Metabase connector was only creating lineage between source tables and dashboards, but not between
source tables and individual charts.

In both _yield_lineage_from_query and _yield_lineage_from_api, added a lineage edge from the source
table to the chart entity in addition to the existing table → dashboard edge.

Validated end-to-end on a local OpenMetadata 1.12.3 instance with a live Metabase connection.

Type of change:

• Bug fix

  Checklist:

  • I have read the CONTRIBUTING document.
  • My PR title is Fixes <issue-number>: <short explanation>
  • I have commented on my code, particularly in hard-to-understand areas.
  • For JSON Schema changes: I updated the migration scripts or explained why it is not needed.
  • I have added a test that covers the exact scenario we are fixing.

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Adds chart-level lineage support for the Metabase connector. Consider moving the chart entity lookup outside the source_tables loop to avoid repeated lookups and improve performance.

💡 Performance: Chart entity lookup repeated inside source_tables loop

📄 ingestion/src/metadata/ingestion/source/dashboard/metabase/metadata.py:459-468

In _yield_lineage_from_query, the chart_fqn/chart_entity lookup (lines 459-468) is inside the for table in lineage_parser.source_tables: loop, but neither depends on table. This means get_by_name is called for the same chart entity on every loop iteration, making a redundant API call per source table.

The pre-existing to_entity (dashboard) lookup has the same issue, so this follows the existing pattern — but the new code doubles the number of redundant API calls per iteration.

Suggested fix

Move both `to_entity` and `chart_entity` lookups above the `for table in lineage_parser.source_tables:` loop (before line 415), since they only depend on `dashboard_name` and `chart_details.id`, not on `table`.

🤖 Prompt for agents

Code Review: Adds chart-level lineage support for the Metabase connector. Consider moving the chart entity lookup outside the source_tables loop to avoid repeated lookups and improve performance.

1. 💡 Performance: Chart entity lookup repeated inside source_tables loop
   Files: ingestion/src/metadata/ingestion/source/dashboard/metabase/metadata.py:459-468

   In `_yield_lineage_from_query`, the `chart_fqn`/`chart_entity` lookup (lines 459-468) is inside the `for table in lineage_parser.source_tables:` loop, but neither depends on `table`. This means `get_by_name` is called for the same chart entity on every loop iteration, making a redundant API call per source table.
   
   The pre-existing `to_entity` (dashboard) lookup has the same issue, so this follows the existing pattern — but the new code doubles the number of redundant API calls per iteration.

   Suggested fix:
   Move both `to_entity` and `chart_entity` lookups above the `for table in lineage_parser.source_tables:` loop (before line 415), since they only depend on `dashboard_name` and `chart_details.id`, not on `table`.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

💡 Performance: Chart entity lookup repeated inside source_tables loop

In _yield_lineage_from_query, the chart_fqn/chart_entity lookup (lines 459-468) is inside the for table in lineage_parser.source_tables: loop, but neither depends on table. This means get_by_name is called for the same chart entity on every loop iteration, making a redundant API call per source table.

The pre-existing to_entity (dashboard) lookup has the same issue, so this follows the existing pattern — but the new code doubles the number of redundant API calls per iteration.

Suggested fix:

Move both `to_entity` and `chart_entity` lookups above the `for table in lineage_parser.source_tables:` loop (before line 415), since they only depend on `dashboard_name` and `chart_details.id`, not on `table`.

_{Was this helpful? React with 👍 / 👎 | Reply gitar fix to apply this suggestion}