Is your feature request related to a problem? Please describe.
The dictionary / referenced-value hint in the data editor currently resolves only one level deep. When tables are normalized and the meaningful human-readable value lives two or more FK hops away, the hint becomes useless.
Concrete example: an assignment table has employee_id → employee. The employee table itself does not store the person's name — it only has things like employee_code, hire_date, and person_id → person, where first_name / last_name actually live. The dictionary on assignment.employee_id can at best show me employee_code (or email, or whatever was auto-picked), which is often cryptic and doesn't help identify the row at a glance.
Describe the solution you'd like
Make dictionary / reference-value resolution cascading (transitive) across FK chains.
If table A references table B, and B itself is configured (or can be auto-detected) to have its own description in table C, DBeaver should follow the chain and display C's description next to A's FK column.
Ideally:
Auto-detect short chains (2–3 hops) when the intermediate table has no name-like column but does have a single FK to a table that has one.
Is your feature request related to a problem? Please describe.
The dictionary / referenced-value hint in the data editor currently resolves only one level deep. When tables are normalized and the meaningful human-readable value lives two or more FK hops away, the hint becomes useless.
Concrete example: an assignment table has employee_id → employee. The employee table itself does not store the person's name — it only has things like employee_code, hire_date, and person_id → person, where first_name / last_name actually live. The dictionary on assignment.employee_id can at best show me employee_code (or email, or whatever was auto-picked), which is often cryptic and doesn't help identify the row at a glance.
Describe the solution you'd like
Make dictionary / reference-value resolution cascading (transitive) across FK chains.
If table A references table B, and B itself is configured (or can be auto-detected) to have its own description in table C, DBeaver should follow the chain and display C's description next to A's FK column.
Ideally:
Auto-detect short chains (2–3 hops) when the intermediate table has no name-like column but does have a single FK to a table that has one.