replace and deprecate metadata.table_iterator

[jek]

replacement should document the ordering of yielded tables, and passing reverse=True should return the opposite of that.

the current invocation for reversed output is insane: table_iterator(reverse=False)

[Mike Bayer]

insane...that reverse=True is the default ? oh, ok. how about:

   # return a list, order is from parent->child
   metadata.sorted_tables

   # if you want reverse, just use Python
   reversed(metadata.sorted_tables)

?

[jek]

why add more api? iter(metadata.tables) should just work.

[Mike Bayer]

iter(metadata) ? or do we want to use a dict subclass for metadata.tables ? do we want to make MetaData subclass dict even?

[jek]

i think just the metadata.tables collection.

[Mike Bayer]

let me tell you why metadata.tables itself is quite awkward for this behavior.

• the topological sort can't succeed in all cases. The main example is when tables are reflected, which contain twin mutually dependent foreign keys. This prevents the dictionary from taking a typical "sorted dictionary" approach where all items are kept sorted at all times, and instead would need to sort at the point of object iteration. It also means the metadata.tables collection would sometimes be in a partially broken state, where its keys() and values() methods fail, but its __getitem__() and such still function. In cases like these, there would be no way to get a list of all tables without resorting to dict.values(metadata.tables).

• metadata.tables is a dictionary of table names to table objects. So to get at the collection of tables, first you're calling metadata.tables.values(), not that big a deal, but then this is a sorting dictionary which is sorting based on the values, not the keys. That also seems very awkward to me since that's not at all the usual semantics for an ordered dictionary, where the keys are what is significant with regard to categorization.

So I'm still +1 on a separate item such as metadata.sorted_tables and will probably pursue this for the 0.5.0 release (which needs to happen ASAP RSN )

[jek]

if sorting can't succeed, then iteration order would be undefined as the user would expect. i don't see any strong reason not to do that ordering on demand, or why an implementation would let sort failure exceptions bubble up.

[Mike Bayer]

committed in 427ed1966f0f9ce13df49dcdbe43ce48333e94fa, subject to jek's 80% approval ;)

[Mike Bayer]

Removing milestone: 0.5.0 (automated comment)