On Jan 10, 2006, at 7:49 PM, Michael Bayer wrote:
well I already have a few of the information_schema tables in a package called sqlalchemy.databases.information_schema, and youre free to embellish that package.....
that's pretty much what i've been doing so far ...
it might be more useful, considering the sketchy status of information_schema (plus i think its layout is pretty esoteric for most uses), for each database to export a view of some kind, maybe just two or three selectables, that just provides basic table, column, and constraint information. even if every DB supported information_schema, it still could be preferable...with information_schema, maybe im missing the point or something, but I literally have to decide among (at least) four different tables to figure out how to inspect a foreign key constraint (key_column_usage, constraint_column_usage, referential_constraints, table_constraints, constraint_table_usage...why so many ambiguous tables ??? and with mysql, theyre not even the same tables, and I *still* cant detect foreign keys).
i think at least using information_schema as a baseline is probably useful; let me go ahead and do what i was talking about so you can at least have some code to look at when thinking about how to generalize to be cross-db. d ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
