Michael Bayer wrote: > > 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.
I was only using information_schema as a base (literally a base class implementation), knowing that most or all implementations would have quirks or performance issues and require method overrides. However, I would hope that implementations of information_schema would improve over time and that custom method overrides in subclasses could be removed, making the code cleaner and less complex. In short, start with the standard and go from there. > > 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. reflecttable is very monolithic. Breaking it down into smaller components will make it easier to test. I follow you on adding methods to the Dialects and that seems like a good place for them. I don't know what kind of API sqlalchemy.engine.reflection would have. Is this something you could sketch out? I'd like to work on this. I have to do it anyway and would prefer getting it into SA instead of it being standalone. I've got access to Oracle 8, 9 and 10, Postgres ... and MSSQL (Express), which brings me to another topic. A project like SA needs access to all of the supported database systems for testing. Currently, it seems that developers are hampered because they don't have access to these systems. So I was thinking of ways to improve the situation and the idea I like the best is a VPN consisting of donated database setups. There would be a central VPN host and donors would connect their donated database servers to this host. Developers could then connect to the VPN host and access all of the database systems. With proper firewalling (iptables rules on the tun/tap devices) it should be safe for all parties. --Randall --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
