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:
Category:MySQL Workbench: Modeling Severity:S3 (Non-critical)
Version:5.2.26 OS:Any
Assigned to: CPU Architecture:Any
Tags: columns, metadata, tables

[19 Aug 2010 7:05] Karsten Wutzke
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 :-)
[19 Aug 2010 14:54] Alfredo Kojima
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.
[19 Aug 2010 17:14] Edwin DeSouza
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
[19 Aug 2010 22:44] Karsten Wutzke
Well, then I will change this bug report to "Document all internal WB structures", as


doesn't show that db.Column has a reference to db.Table.
[19 Aug 2010 23:05] Karsten Wutzke
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.
[19 Aug 2010 23:34] Karsten Wutzke
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...
[21 Aug 2010 0:38] Alfredo Kojima
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.
[21 Aug 2010 20:17] Alfredo Kojima
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.