get_foreign_keys() missing @reflection.cache causes excessive DESCRIBE TABLE EXTENDED queries

Open Beginner friendly
#72 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
90/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
python
Domain
database

Research direction

Start in base.py at get_foreign_keys() around line 256 and compare it with get_pk_constraint() around line 211, both of which use _describe_table_extended(). Add the missing reflection cache decorator and verify that DESCRIBE TABLE EXTENDED is issued only once per table during repeated reflection.

Written by the indexing model from the issue text.

Description

Summary

get_foreign_keys() is missing the @reflection.cache decorator, causing a fresh DESCRIBE TABLE EXTENDED query to be issued to the SQL warehouse for every table on every reflection call.

Expected behaviour

Like get_pk_constraint(), has_table(), and get_table_comment(), get_foreign_keys() should be cached per-table per-connection so that DESCRIBE TABLE EXTENDED is only executed once per table during a reflection pass.

Actual behaviour

Every call to get_foreign_keys() unconditionally executes:

DESCRIBE TABLE EXTENDED `catalog`.`schema`.`table`

When reflecting schemas with many tables (or when reflection is triggered repeatedly, e.g. on each request in a web application), this produces a large number of redundant warehouse queries.

Root cause

base.pyget_foreign_keys() at line 256 lacks @reflection.cache. Compare with get_pk_constraint() (line 211) which uses the same _describe_table_extended() helper but is correctly decorated.

Fix

Add @reflection.cache to get_foreign_keys().

Dominant language
Python
Stars
24
Forks
18
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/databricks-sqlalchemy

All issues in databricks/databricks-sqlalchemy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.