Im curious, is the MSSQL dialect rendering tables as "schemaname.tablename" in all cases ? If so, is that really necessary ? All the other dialects don't deal with "schema" at all unless we're reflecting tables and need the schema name for the query, or the "schema" argument is specified on Table. Doesn't MSSQL at least understand that the meaning of "default" schema is, "use this schema if its not specified" ? In particular I'd hope that if I reflected a table called "foo", and it referenced another table in the local schema called "bar", they would both be keyed in the MetaData as "foo" and "bar", and not "dbo.foo" and "dbo.bar". That would actually break our documented usage contract.
On Dec 23, 2008, at 10:32 AM, Rick Morrison wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
