On Sat, Dec 20, 2008 at 9:34 AM, Etienne Robillard
robillard.etie...@gmail.com wrote:
On Wed, 17 Dec 2008 02:48:08 -0600
Jorge Vargas jorge.var...@gmail.com wrote:
Hello, I have been trying to figure out an alternative to the
following setup.
The problem I'm trying to solve is fixing
I just launched last week a site running on 0.5rc4, given the quality
of SA releases you shouldn't fear it's not final tag. It's really
stable the only thing that could stop you from deploying is a hard
policy on what goes to prod, by your organization/company/etc.
On Thu, Dec 18, 2008 at 7:54
Hi all,
I'm trying to port to python 2.6 with SQLAlchemy over PostgrSQL and it
seems that all is porting BUT the psycopg2 component?
Is anyone aware of a working version of psycopg2 for Linx 64 arch?
In general - does SQLAlchemy support 2.6? I was under the impression
that it does.
Is there
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
Over the last couple days I have been having an issue with relations/
imports. I have a class called queue where I define all my columns.
Within queue I have a function that references a class filequeue so I
need to 'from filequeues import filequeue'. The queue class itself
has relations with
we're good for 2.6 and in particular the 0.5.0 trunk (post rc4) is
tested on 2.6, and even runs fairly well with the -3 flag.
On Dec 23, 2008, at 8:04 AM, vctr...@gmail.com wrote:
Hi all,
I'm trying to port to python 2.6 with SQLAlchemy over PostgrSQL and it
seems that all is porting
ForeignKey accepts strings to remove the inconvenience of handling
circular imports. Both dependent tables will need to be present
within the shared MetaData object at the point at which the Table
object is first used, though, so another module that imports both
queue and filequeue
I am not sure based on the project if I can have a module that imports both
of them. How can I use the string based ForeignKey? I may be doing it in
correctly because it says the table does not exist that I try to reference.
On Tue, Dec 23, 2008 at 12:18 PM, Michael Bayer
thats because both Table objects need to be present in the MetaData
when used. Ultimately your application can't run unless both queue
and filequeue have been imported in some way.
On Dec 23, 2008, at 1:21 PM, Michael Mileusnich wrote:
I am not sure based on the project if I can have a
I have a py file that creates my tables. It does MetaData =
queue.metadata. metadata.create_all(). That's all I do with MetaData. Is
there additional table setup I need to be doing?
On Tue, Dec 23, 2008 at 12:24 PM, Michael Bayer mike...@zzzcomputing.comwrote:
thats because both Table
On Dec 23, 2008, at 1:29 PM, Michael Mileusnich wrote:
I have a py file that creates my tables. It does MetaData =
queue.metadata. metadata.create_all(). That's all I do with
MetaData. Is there additional table setup I need to be doing?
yeah have it do import filequeue; import
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
ondelete and onupdate are keyword arguments within ForeignKey()
itself, and they come out as part of the DDL when you call
metadata.create_all().
On Dec 23, 2008, at 8:42 PM, justmike2...@gmail.com wrote:
I seem to be running into a problem with implementing cascades in
sqlalch. Next to
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.
Yea I do the ondelete and onupdate in ForeignKey, creates tables and all but
does not do the cascade or at least not in MSSQL.
On Tue, Dec 23, 2008 at 7:42 PM, justmike2...@gmail.com
justmike2...@gmail.com wrote:
I seem to be running into a problem with implementing cascades in
sqlalch.
generates the ON DELETE CASCADE in the DDL, versus the cascade does
not work, are two different issues. Which are you experiencing, and
if the latter, how is the issue manifesting itself ? Can you produce
sample code which reproduces your issue ?
On Dec 23, 2008, at 10:19 PM, Michael
code:
queue_table = Table(
'QUEUES', metadata,
Column('QUEUEID', Integer, autoincrement=True, primary_key=True),
Column('JOBNUM', String(48), ForeignKey('JOBS.JOBNUM',
onupdate=CASCADE, ondelete=CASCADE)),
Column('SCHEDID', String(48),
20 matches
Mail list logo