feature: virtual foreign keys #99

New issue

Open

opened 2026-07-15 17:49:06 -05:00 by noe.trevino · 0 comments

noe.trevino commented

2026-07-15 17:49:06 -05:00

Owner

Did you check the docs?

I have read all the dadbod-ui.nvim docs

Foreign key jump only works when the schema actually declares the foreign key. Views dont. Myisam doesnt. Plenty of warehouses dont bother declaring them at all.

So the feature quietly stops existing depending on what you opened, and views are always a dead end.

Describe the solution you'd like

Let me declare a foreign key that isnt in the schema, persist it in config, and have foreign key jump treat it like a real one.

Its a config file plus a lookup in the jump path we already have, so its cheap for what it gives back. It makes an existing feature work in the places it currently gives up.

Acceptance Criteria

can declare a foreign key that isnt in the schema
persists across restarts
stored in config
foreign key jump uses it the same as a real one
works on views
can edit or delete one
real foreign keys still win if theres a conflict

Describe alternatives/other solutions you've considered

Nothing, and living with it. Thats today. Means views are dead ends and constraint-less schemas get none of the navigation.

Virtual unique keys too, like DBeaver has. Theirs exists to make grid editing work on tables without a primary key, and we decided against editable grids, so theres no reason for it yet.

### Did you check the docs? - [X] I have read all the dadbod-ui.nvim docs ### Is your feature request related to a problem? Please describe. Foreign key jump only works when the schema actually declares the foreign key. Views dont. Myisam doesnt. Plenty of warehouses dont bother declaring them at all. So the feature quietly stops existing depending on what you opened, and views are always a dead end. ### Describe the solution you'd like Let me declare a foreign key that isnt in the schema, persist it in config, and have foreign key jump treat it like a real one. Its a config file plus a lookup in the jump path we already have, so its cheap for what it gives back. It makes an existing feature work in the places it currently gives up. ### Acceptance Criteria - [ ] can declare a foreign key that isnt in the schema - [ ] persists across restarts - [ ] stored in config - [ ] foreign key jump uses it the same as a real one - [ ] works on views - [ ] can edit or delete one - [ ] real foreign keys still win if theres a conflict ### Describe alternatives/other solutions you've considered Nothing, and living with it. Thats today. Means views are dead ends and constraint-less schemas get none of the navigation. Virtual unique keys too, like DBeaver has. Theirs exists to make grid editing work on tables without a primary key, and we decided against editable grids, so theres no reason for it yet.