I went on writing support for fetching table keys so we can put key icon (for example) next to primary/foreign keys on diagram (so it would make more sense) or even on the column listing in the sidebar. In short we need names of columns which are foreign and primary keys.
So here are the possibilities how to implement that:
Integrate it in listTableColumns method and add one more attribute to returning value. - Easiest and it's not breaking change. However this requires at least one extra join which makes query a bit slower. Not much slower, but since we use this on collapsing table sub menu, user might feel it's a bit laggy. Pro: We could show key icon next to columns name in database list (like in SQL Server studio). Con: Slows down fetching (only) table columns names.
Change getTableReferences method so that it returns object containing referenced table (as it does now) and additionally column name and key type. For primary key referenced table would be null. This is option I feel most intuitive because we are reading it from the same table(s). This way we could show table keys under separate table sub menu (name Keys or something like that). It's the way all three major clients work - Workbench, pgAdmin and SQL Server studio. Pro: Good approach. Con: It's a breaking change.
Make new method - getTableKeys and call it whenever we need (diagram, keys sub menu, on listing column names...). Pro: Flexibility I guess...
@maxcnunes Your two cents, which option to go with?
Well, all the options looks good. But getTableReferences really looks more intuitive. And since all major clients follow that approach I guess we could base on that.
I went on writing support for fetching table keys so we can put key icon (for example) next to primary/foreign keys on diagram (so it would make more sense) or even on the column listing in the sidebar. In short we need names of columns which are foreign and primary keys.
So here are the possibilities how to implement that:
listTableColumns
method and add one more attribute to returning value. - Easiest and it's not breaking change. However this requires at least one extra join which makes query a bit slower. Not much slower, but since we use this on collapsing table sub menu, user might feel it's a bit laggy. Pro: We could show key icon next to columns name in database list (like in SQL Server studio). Con: Slows down fetching (only) table columns names.getTableReferences
method so that it returns object containingreferenced table
(as it does now) and additionallycolumn name
andkey type
. For primary key referenced table would benull
. This is option I feel most intuitive because we are reading it from the same table(s). This way we could show table keys under separate table sub menu (name Keys or something like that). It's the way all three major clients work - Workbench, pgAdmin and SQL Server studio. Pro: Good approach. Con: It's a breaking change.getTableKeys
and call it whenever we need (diagram, keys sub menu, on listing column names...). Pro: Flexibility I guess...@maxcnunes Your two cents, which option to go with?