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
Rick,
On Tue, Dec 23, 2008 at 10:32 AM, Rick Morrison rickmorri...@gmail.comwrote:
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
Im curious, is the MSSQL dialect rendering tables as
schemaname.tablename in all cases ?
No, I don't think so: the module uses non-overridden calls to
compiler.IdentifierPreparer.format_table() and format_column().
So then the only usage of the get_default_schema_name() is for table
existence
On Dec 23, 2008, at 2:15 PM, Rick Morrison wrote:
Im curious, is the MSSQL dialect rendering tables as
schemaname.tablename in all cases ?
No, I don't think so: the module uses non-overridden calls to
compiler.IdentifierPreparer.format_table() and format_column().
So then the only
Michael Bayer wrote:
so if we can confirm this ! .socloseto...release
From grepping:
For the Oracle dialect get_default_schema_name is used in reflecttable,
has_table and has_sequence. has_table, in turn, is used by the
SchemaGenerator and SchemaDropper.
MSSQL
On Tue, Dec 23, 2008 at 3:34 PM, Randall Smith rand...@tnr.cc wrote:
Michael Bayer wrote:
so if we can confirm this ! .socloseto...release
From grepping:
For the Oracle dialect get_default_schema_name is used in reflecttable,
has_table and has_sequence.
Michael Bayer wrote:
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.
The mssql dialect does not ask the
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
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.
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
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.
On Mon, Dec 22, 2008 at 8:46 PM, Empty mtr...@gmail.com wrote:
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
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
Michael Bayer wrote:
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Ticket 1258
-Randall
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this
On Mon, Dec 22, 2008 at 10:00 PM, Randall Smith rand...@tnr.cc wrote:
Michael Bayer wrote:
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Ticket 1258
Nice. Thank you very much.
Michael
--~--~-~--~~~---~--~~
You received
On Mon, Dec 22, 2008 at 10:45 PM, Empty mtr...@gmail.com wrote:
On Mon, Dec 22, 2008 at 10:00 PM, Randall Smith rand...@tnr.cc wrote:
Michael Bayer wrote:
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Ticket 1258
Fixed in r5527.
Thanks again,
Hi,
The more I think about this, the more I'm becoming convinced that
specifying an implicit default schema in all generated SQL is a pretty
bad idea. The reason is that it would break a feature in a few
database engines that might be called schema cascade, or Postgres
explicitly calls
there's just a few odd places, and I wonder if drop table is one of
them, resulting in the original cause of this thread.
I don't think that DROP is a special case. Look upthread. The incorrect DROP
happened in the same wrong schema as the incorrect CREATE. The problem is
that the check-table
2007/8/13, Rick Morrison [EMAIL PROTECTED]:
That SQL log is from the table existence check.
Although it's unclear from the trace and log as to
whether the check is for the table create
or for the table drop, it is correctly using
the default schema, which is 'dbo' on all
MSSQL platforms.
It's for the delete (which then does not happen because the table is not
found)
Sure, but the drop is being issued in the correct default schema (dbo). The
error is not that the drop is being issued in the wrong schema, it is that
the table was *created* in the wrong schema, and so is not where
2007/8/14, Rick Morrison [EMAIL PROTECTED]:
It's for the delete (which then does not happen because the table is not
found)
Sure, but the drop is being issued in the correct default schema (dbo).
No it's not. If I don't enable checkfirst the table is dropped, which
means both statements are
Sure, but the drop is being issued in the correct default schema (dbo).
No it's not. If I don't enable checkfirst the table is dropped, which
means both statements are issued on the wrong schema (considering that
the check is right).
Ah OK I didn't get that from the previous
messages. Then it
Should ansisql recognize and use default schemas,
or should the DB dialect somehow override the construction of the table
name?
The more I think about this, the more I'm becoming convinced that specifying
an implicit default schema in all generated SQL is a pretty bad idea. The
reason is that
Hi,
I still have problems with the default_schema and the way it's
handled in the mssql backend.
Ok, as a workaround for now, specify the schema explicitly for all your
tables. That's what I do and it works great for me.
Clearly this problem needs to be fixed though; please create a ticket
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
That SQL log is from the table existence check.
Although it's unclear from the trace and log as to whether the check
is for the table create or for the table drop, it is correctly using
the default schema, which is 'dbo' on all MSSQL platforms.
So, the table check and the drop are working
23 matches
Mail list logo
