I've got a few concerns with the just-committed get_default_schema_name() approach:
1) What about pre-2005 users? The query used in this patch to fetch the schema name won't work. There was not even a real hard concept of 'schema' pre-MSSQL-2005. 2) Prior to MSSQL 2005, MSSQL conflated user name and schema name in a fashion similar to that of Oracle. People use this to "override" some tables, because the server search for locating a table in Oracle and MSSQL is to check the "user" schema first, then look through a schema search path looking for a table matching the given identifier. So if you have a table named [mylogin.tablename] and there is also a table [public.tablename], if you issue "SELECT * FROM tablename", you'll get the contents of [public.tablename] UNLESS you're logged in as 'mylogin', in which case you'll get the contents of [mylogin.tablename]. This is IMO a kind of questionable practice, but there are existing uses like this out there, and making the default schema always explicit breaks this. Note this is not only a pre-MSSQL2005 issue, I think 2005+ will still recognize "user" style schemas. 3) Isn't Micheal's concern below still valid? > just FTR, the current expected behavior of default schemas is that if > your tables are known to exist in the default schema configured on the > database connection, you leave the "schema" attribute on Table blank. > otherwise, you set it. > > this is actually a convention that we've had to choose. if the two > conventions are mixed, table reflection gets confused over whether to > look for/place tables with the key "tablename" or > "schemaname.tablename" into the MetaData object. While we could try > building an enhanced "key" object which hashes both "tablename" and > "schema.tablename" as the same "key" depending on the default schema > of the DB, this requires a live connection to the database in order to > function, and as we all know a MetaData can be bound to a DB later > on...so for now we have the convention. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
