On Nov 7, 2008, at 1:46 PM, Randall Smith wrote:
> > To my knowledge, there doesn't exist a tool to extract schema > information from a database with a database independent API. SA does > this to some extent by providing "table_names" and "reflectable" > methods > on it's Engine class, but I think it would be nice to have something > more comprehensive and fine grained. > > It seems to me that ORM is only a part of SA's function. I've used > SA's > connection, cursor (ResultProxy) and SQL abstractions without ORM as a > kind of higher level DBAPI with good results. I think that a schema > information API would fit well into SA's theme. The implementation > could make use of the non-ORM features as well as providing for some > other features like table reflection. > > How would it fit in? I think it should be usable without requiring > the > use of other SA facilities. Maybe like this: We did long ago attempt to build an "information schema" API, which was based on the information schema specification, before realizing that this model hardly works in any current RDBMS (for example, its excruciatingly slow on postgres) and is entirely inconsistent in any case (the queries to be used on MySQL are entirely different than those of PG, and MySQL doesn't even give you enough information to reconstruct a table with all of its constraints). I've looked at your sample code and I see it is based on information schema, so that aspect of it in my experience isn't going to travel very well. But an open API to our existing reflection facilities, adding in things like views and indexes, is a great idea. Since the dialects already have a great deal of inspection logic built in it would make sense that the current table reflection functions would build on top of these functions, since that's already what its doing. So the work I'd be willing to accept in this area would include adding additional Dialect functions which accomplish all the desired functionality of reading views, indexes, etc., building a front-end API on top of it which I'd probably call sqlalchemy.engine.reflection, and the biggest job of all would be comprehensive unit tests, for which I'd even make a new package, tests/reflection/*. We currently have tests/engine/reflection.py which is a pretty old module and could use a good deal of cleanup. I would gladly give commit access to anyone who wanted to take on this task, working in a branch to start which would later be merged to trunk. In particular we have a good deal of MS-SQL bugs regarding reflection, even a new one just today, that are in need of fixing. I dont have regular access to MS-SQL on my end so I rarely get to work with that code. One of the major tedious elements here is that the reflection code is custom for each dialect. Based on my experiences with information schema, I don't think there's any way around this. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
