fix(oracle): restore catalog-aware constraint reflection

[IceS2]

Backports #31676 to 1.13.

This applies catalog-aware Oracle primary-key, unique-constraint, and foreign-key reflection and preserves backing-index metadata.

Focused verification: 4 Oracle constraint-reflection tests passed.

Greptile Summary

The PR restores catalog-aware Oracle constraint reflection by overriding primary-key, unique-constraint, and foreign-key reflection while preserving backing-index metadata.

• Uses the configured DBA_* or ALL_* Oracle catalog views for constraint queries.
• Resolves synonyms and database links before reflecting constraints.
• Adds focused tests for catalog selection, empty results, synonym resolution, foreign keys, and composite unique constraints.

Confidence Score: 5/5

The PR appears safe to merge; no concrete changed-code defect or security issue was identified.

The new reflection methods preserve the expected constraint shapes, select from the configured Oracle catalog, handle synonym targets before querying, and are covered by focused regression tests.

Important Files Changed

Filename	Overview
ingestion/src/metadata/ingestion/source/database/oracle/metadata.py	Rebinds the Oracle dialect’s public constraint-reflection methods to catalog-aware connector implementations.
ingestion/src/metadata/ingestion/source/database/oracle/queries.py	Extends the constraint query with the backing index name required for unique-constraint metadata.
ingestion/src/metadata/ingestion/source/database/oracle/utils.py	Adds cached primary-key, unique-constraint, and foreign-key reflection with shared synonym, schema, and database-link preparation.
ingestion/tests/unit/topology/database/test_oracle_constraint_reflection.py	Covers both supported catalog prefixes, reflected constraint shapes, empty defaults, and synonym resolution.

_{Reviews (1): Last reviewed commit: "fix(oracle): restore catalog-aware const..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Ingestion Framework

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[github-actions]

The Python checkstyle failed.

Please run make py_format and py_format_check in the root of your repository and commit the changes to this PR.
You can also use pre-commit to automate the Python code formatting.

You can install the pre-commit hooks with make install_test precommit_install.

[gitar-bot]

⚠️ Bug: Synonym path skips name denormalization when no synonym found

When oracle_resolve_synonyms=True but _get_synonyms returns no rows (i.e. the object is a regular table, not a synonym), _prepare_constraint_args leaves table_name/schema as the normalized (lowercase) values received from the inspector and never calls denormalize_name. The constraint query then matches ac.table_name = :table_name/ac.owner = :owner against Oracle's uppercase data dictionary and returns nothing, so PK/unique/FK constraints silently disappear. SQLAlchemy's original _prepare_reflection_args always falls back to denormalize_name(table_name) and denormalize_name(schema or default_schema_name) when no synonym is resolved. Add the same fallback in the if rows: branch's else path.

Denormalize table/schema even when synonym resolution yields no rows.:

if kw.get("oracle_resolve_synonyms", False):
    rows = list(
        self._get_synonyms(
            connection, schema, [table_name], dblink,
            info_cache=kw.get("info_cache"),
        )
    )
    if rows:
        row = rows[0]
        table_name = self.denormalize_name(row.table_name)
        schema = self.denormalize_name(row.table_owner)
        if row.db_link:
            dblink = row.db_link if row.db_link.startswith("@") else f"@{row.db_link}"
    else:
        table_name = self.denormalize_name(table_name)
        schema = self.denormalize_name(schema or self.default_schema_name)
else:

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

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 1 findings

Backports catalog-aware constraint reflection for Oracle databases. Synonym path skips name denormalization when no synonym found, which needs to be addressed.

⚠️ Bug: Synonym path skips name denormalization when no synonym found

📄 ingestion/src/metadata/ingestion/source/database/oracle/utils.py:456-470

When oracle_resolve_synonyms=True but _get_synonyms returns no rows (i.e. the object is a regular table, not a synonym), _prepare_constraint_args leaves table_name/schema as the normalized (lowercase) values received from the inspector and never calls denormalize_name. The constraint query then matches ac.table_name = :table_name/ac.owner = :owner against Oracle's uppercase data dictionary and returns nothing, so PK/unique/FK constraints silently disappear. SQLAlchemy's original _prepare_reflection_args always falls back to denormalize_name(table_name) and denormalize_name(schema or default_schema_name) when no synonym is resolved. Add the same fallback in the if rows: branch's else path.

Denormalize table/schema even when synonym resolution yields no rows.

if kw.get("oracle_resolve_synonyms", False):
    rows = list(
        self._get_synonyms(
            connection, schema, [table_name], dblink,
            info_cache=kw.get("info_cache"),
        )
    )
    if rows:
        row = rows[0]
        table_name = self.denormalize_name(row.table_name)
        schema = self.denormalize_name(row.table_owner)
        if row.db_link:
            dblink = row.db_link if row.db_link.startswith("@") else f"@{row.db_link}"
    else:
        table_name = self.denormalize_name(table_name)
        schema = self.denormalize_name(schema or self.default_schema_name)
else:

🤖 Prompt for agents

Code Review: Backports catalog-aware constraint reflection for Oracle databases. Synonym path skips name denormalization when no synonym found, which needs to be addressed.

1. ⚠️ Bug: Synonym path skips name denormalization when no synonym found
   Files: ingestion/src/metadata/ingestion/source/database/oracle/utils.py:456-470

   When `oracle_resolve_synonyms=True` but `_get_synonyms` returns no rows (i.e. the object is a regular table, not a synonym), `_prepare_constraint_args` leaves `table_name`/`schema` as the normalized (lowercase) values received from the inspector and never calls `denormalize_name`. The constraint query then matches `ac.table_name = :table_name`/`ac.owner = :owner` against Oracle's uppercase data dictionary and returns nothing, so PK/unique/FK constraints silently disappear. SQLAlchemy's original `_prepare_reflection_args` always falls back to `denormalize_name(table_name)` and `denormalize_name(schema or default_schema_name)` when no synonym is resolved. Add the same fallback in the `if rows:` branch's else path.

   Fix (Denormalize table/schema even when synonym resolution yields no rows.):
   if kw.get("oracle_resolve_synonyms", False):
       rows = list(
           self._get_synonyms(
               connection, schema, [table_name], dblink,
               info_cache=kw.get("info_cache"),
           )
       )
       if rows:
           row = rows[0]
           table_name = self.denormalize_name(row.table_name)
           schema = self.denormalize_name(row.table_owner)
           if row.db_link:
               dblink = row.db_link if row.db_link.startswith("@") else f"@{row.db_link}"
       else:
           table_name = self.denormalize_name(table_name)
           schema = self.denormalize_name(schema or self.default_schema_name)
   else:

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}