MySQL Bugs: #56110: Missing methods db.Column: getTable() and db.Table: getReferencingForeignKeys()

Bug #56110	Missing methods db.Column: getTable() and db.Table: getReferencingForeignKeys()
Submitted:	19 Aug 2010 7:05	Modified:	21 Aug 2010 20:17
Reporter:	Karsten Wutzke	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S3 (Non-critical)
Version:	5.2.26	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	columns, metadata, tables

Description:
The internal structure should implement getTable() for db.Column and db.Table should save all incoming (referencing) foreign keys. This would allow plugin developers to navigate through the entire model *much* more easily without having to build crutches for missing but needed information.

I flagged this as S3 to reflect the importance of these methods. It shouldn't be too hard to implement.

How to repeat:
Write a fairly complex plugin :-)

The owner field of db.Column points to the table and getReferencingForeignKeys is already available
in db.Schema as getForeignKeysReferencingTable()

You can get the schema for a table through the owner field of the table.

Hi Karsten,

Assuming you are creating another excellent open source plugin for MySQL Workbench, but this one is written in Python...

If you blog/publish the early/Alpha version, Alfredo may be able to:
1)  Give advice on existing WB Plugin features that you can leverage right now
2)  Add to WB Roadmap to make Plugin Development easier (in the future)

- Edwin

Well, then I will change this bug report to "Document all internal WB structures", as

http://wb.mysql.com/workbench/doc/globals/classdb___column.html

doesn't show that db.Column has a reference to db.Table.

DOH. RT(F)M. Sorry, you were right. I didn't realize that *all* GrtObject's have an owner. Hmmm maybe the docs should reflect what's effectively available to a class...? Looking into every super class can be annoying and as you saw can cause people to overlook things.

What irritated me was the fact that db.ForeignKey defines a property called owner of type db.Table (shell tree Ctrl-F3). This made me think owner couldn't be declared in a super class and thus made no attempts to look for such a property for other classes...

It is true that the owner field and some others that are inherited from superclasses are not too obvious. Since the number of interesting fields from them are limited, I'll add a section to the documentation covering them, since they are common to everything else.

The following paragraph is in the home page for the globals/grt classes documentation:

All object nodes descend from a base GrtObject class. It has a name and owner fields. The owner field must alway point to the object that precedes it in the globals tree hierarchy, eg: a column is owned by a table, a table is owned by a schema, a schema by a catalog and so on up to the root node, which is an instance of workbench_Workbench.

I'll close this feature request, if you have further questions or suggestions, please reopen this bug or directly email me.