Hi,
Note the following code:
oj=outerjoin(s,f)
r1=select([oj]).execute().fetchall()
r2=select([oj.left.c.id, oj.right.c.status]).execute().fetchall()
The first select executes a LEFT OUTER JOIN and returns all columns.
I wanted only 2 specific columns, so I tried the 2nd select.
That does not
-Original Message-
From: sqlalchemy@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of mc
Sent: 15 August 2007 14:23
To: sqlalchemy
Subject: [sqlalchemy] Outerjoin with a subset of columns
Hi,
Note the following code:
oj=outerjoin(s,f)
It certainly did help .
many thanks
On Aug 15, 4:41 pm, King Simon-NFHD78 [EMAIL PROTECTED]
wrote:
-Original Message-
From: sqlalchemy@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of mc
Sent: 15 August 2007 14:23
To: sqlalchemy
Subject: [sqlalchemy] Outerjoin with a
On Wednesday 15 August 2007 04:26:31 Michael Bayer wrote:
On Aug 14, 2007, at 4:35 PM, Michael Bayer wrote:
On Aug 14, 2007, at 12:38 PM, svilen wrote:
---
orm.attribute
AttributeManager.init_attr():
the saving this one eventualy does is too small, compared to
a property
Hi All,
Recently I upgraded to the version 3.9 of SA. Post that whenever I am trying
to save characters in different language in the table I am getting the below
exception:
File /src/sqlalchemy/engine/base.py,
line 601, in _execute
raise exceptions.SQLError(context.statement,
Arun Kumar PG wrote:
Hi All,
Recently I upgraded to the version 3.9 of SA. Post that whenever I am
trying to save characters in different language in the table I am
getting the below exception:
File /src/sqlalchemy/engine/base.py,
line 601, in _execute
raise
All tables are having a charset of utf8. Additionally, I am issuing SET
NAMES 'utf8' statement as a part of connection establishment.
Anything that is wrong here or missing ?
On 8/15/07, jason kirtland [EMAIL PROTECTED] wrote:
Arun Kumar PG wrote:
Hi All,
Recently I upgraded to the
Hi,
I've encountered a strange behaviour when mapping a table which
hasn't got a PrimaryKeyConstraint declared but a primary_key is
declared when building the mapper (in order to be able to map it).
Queries through the mapper work fine until the limit keyword is
used. Am I doing something
Arun Kumar PG wrote:
All tables are having a charset of utf8. Additionally, I am issuing SET
NAMES 'utf8' statement as a part of connection establishment.
Anything that is wrong here or missing ?
Are you updating the connection character set in the driver as well
after issuing SET NAMES?
On Tuesday 14 August 2007 23:05:44 Michael Bayer wrote:
On Aug 14, 2007, at 3:30 PM, [EMAIL PROTECTED] wrote:
databases/sqlite: (reflecttable)
pragma_names is missing the BOOLEAN word/type - nulltype
btw why isn't each dialect-typeclass adding it's own entry to
that pragma_names,
thats definitely not going to work right now. I added feature
enhancement # 740, currently its milestone 5 unless we start getting
more time for some of these things. put primary_key on your Table
for now.
On Aug 15, 2007, at 12:04 PM, Alberto Valverde wrote:
from sqlalchemy import *
are you using convert_unicode=True and/or the Unicode type ?
On Aug 15, 2007, at 12:01 PM, Arun Kumar PG wrote:
All tables are having a charset of utf8. Additionally, I am issuing
SET NAMES 'utf8' statement as a part of connection establishment.
Anything that is wrong here or missing ?
On Aug 15, 2007, at 6:55 PM, Michael Bayer wrote:
thats definitely not going to work right now. I added feature
enhancement # 740, currently its milestone 5 unless we start
getting more time for some of these things. put primary_key on your
Table for now.
I've disabled the eager
On Aug 15, 2007, at 1:35 PM, Alberto Valverde wrote:
On Aug 15, 2007, at 6:55 PM, Michael Bayer wrote:
thats definitely not going to work right now. I added feature
enhancement # 740, currently its milestone 5 unless we start
getting more time for some of these things. put primary_key on
Yes. it's being done. I create the engine and then set convert unicode =
True.
On 8/15/07, Michael Bayer [EMAIL PROTECTED] wrote:
are you using convert_unicode=True and/or the Unicode type ?
On Aug 15, 2007, at 12:01 PM, Arun Kumar PG wrote:
All tables are having a charset of utf8.
Any other clue that may be helpful in troubleshooting the cause ?
On 8/15/07, Arun Kumar PG [EMAIL PROTECTED] wrote:
Yes. it's being done. I create the engine and then set convert unicode =
True.
On 8/15/07, Michael Bayer [EMAIL PROTECTED] wrote:
are you using convert_unicode=True
I had in mind that the metaclass approach would be used, but not
necesarily with the walking stuff going on.
if you really want to think about this, the idea for a types overhaul
is ticket #526. that breaks up the DDL from the adaptation side
of things. a metaclass approach would be at
hi Jeronimo -
eager loading of self-referential relationships is not supported in
version 0.3. this is a new feature as of version 0.4, using the
join_depth option to indicate how many levels deep youd like to
eagerly-join. in any case, even when eager loading is specified, the
load
On Wednesday 15 August 2007 19:51:30 Michael Bayer wrote:
On Aug 15, 2007, at 10:52 AM, [EMAIL PROTECTED] wrote:
Second, i went to r3312, let init_attr() set a _state as plain
dict and removed _state as property. The difference
plain-dict/property (in favor of plain dict) is like 2-3%.
Hi,
I have two questions:
1) what exact versions of MySQL (i.e. 4.1.22) and py-mysqldb?
2) how many databases and/or tables (an encodings) used in your
application?
On Aug 15, 9:57 pm, Arun Kumar PG [EMAIL PROTECTED] wrote:
Any other clue that may be helpful in troubleshooting the cause
So to recap, you are setting the character set on the dbapi
connection via the MySQLdb method in addition to issuing a manual
SET NAMES query?
Arun wrote:
Any other clue that may be helpful in troubleshooting the cause ?
On 8/15/07, Arun Kumar PG [EMAIL PROTECTED] wrote:
Yes. it's
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
Right now i'm considering changing to 0.4 .
Assign 2 different classes to the same table was the first thing that
i thought, because A and B are
exactly the same, the only difference is that only one kind of A
( the B class :) ) can have a parent A but no children.
The A class can have many B as
On Aug 15, 2007, at 7:48 PM, Michael Bayer wrote:
On Aug 15, 2007, at 1:35 PM, Alberto Valverde wrote:
On Aug 15, 2007, at 6:55 PM, Michael Bayer wrote:
thats definitely not going to work right now. I added feature
enhancement # 740, currently its milestone 5 unless we start
getting
I am using mysqldb-1.2.2. I am passing 'SET NAMES' to connect method as a
value for init_command parameter. All tables have utf8 charset. And I pass
convert_unicode=True to engine.
Let me know if anything else is required.
thanks!
On 8/15/07, jason kirtland [EMAIL PROTECTED] wrote:
So to
Ok you need to get tArun wrote:
I am using mysqldb-1.2.2. I am passing 'SET NAMES' to connect
method as a value for init_command parameter. All tables have
utf8 charset. And I pass convert_unicode=True to engine.
Let me know if anything else is required.
Ok, you need to get that charset to
On Wednesday 15 August 2007 20:54:27 Michael Bayer wrote:
I had in mind that the metaclass approach would be used, but not
necesarily with the walking stuff going on.
the walking is a quick and dirty and very simple way to get away with
it - for now.
if you really want to think about this,
I'm (finally) working on 0.4 compatibility in a couple of small
applications at work. One issue that is cropping up is that when using
sqlite, columns that are defined like this:
Column('established', TIMESTAMP(timezone=True), nullable=False,
Reflection should be configurable whether to stop at dialect
level (SLint) or go back to abstract types (types.Int) - see my
autoload.py.
why would one want to stop the reflection from going back to abstract
types?
i.e. if the current reflection (dialevt-level) is made to autoguess
the
On Thursday 16 August 2007 00:33:57 [EMAIL PROTECTED] wrote:
Reflection should be configurable whether to stop at dialect
level (SLint) or go back to abstract types (types.Int) - see my
autoload.py.
why would one want to stop the reflection from going back to
abstract types?
i.e. if the
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
On Aug 15, 2007, at 6:22 PM, JP wrote:
Is there a different way to do this that's compatible with both
versions, or is there a new 0.4 way of doing this, or have I just been
doing something wrong all along and only 0.4 is catching it?
DateTime objects in sqlite currently expect a
Hi,
I am using sqlalchemy like this:
class Entry: pass
table1 = sqa.Table('table1', meta, autoload=True) # this table has
primary key 'id'
table2 = sqa.Table('table2', meta, sqa.Column('table1_id',
sqa.Integer, sqa.ForeignKey('table1.id'), autoload=True)
table1 = table1.join(table2) # gets
I just installed the latest 0.3 version of SA (0.3.10).
How does one tell SqlAlchemy to cascade on delete within the TG layer?
I use MySql with InnoDB and I have ondelete cascade working on the
tables. So, if I delete an account, the user records are correctly
deleted.
But with SA, deleting an
I just installed the latest 0.3 version of SA (0.3.10).
How does one tell SqlAlchemy to cascade on delete within a TurboGears
context?
I use MySql with InnoDB and I have ondelete cascade working on the
tables. So, if I delete an account directly via sql, the user records
are correctly deleted.
35 matches
Mail list logo
