Just to be painfully complete the solution was:
subquery = select([Taggable.c.id], query._criterion,
from_obj= query._from_obj).as_scalar()
names.select (exists ([names.c.id],
and_(names.c.id == obj_tags.c.name_id,
On Nov 27, 2007, at 11:51 PM, kris wrote:
>
>
> I tried
>
> names.select (exists ([names.c.id],
> and_(names.c.id == obj_tags.c.name_id,
>obj_tags.c.parent_id==Taggable.c.id ,
>Taggable.c.id == query.compile()
I tried
names.select (exists ([names.c.id],
and_(names.c.id == obj_tags.c.name_id,
obj_tags.c.parent_id==Taggable.c.id ,
Taggable.c.id == query.compile() )
however, I am getting too many fields back with the
On Nov 27, 2007, at 8:18 PM, kris wrote:
>
> I am trying to do a select on the results an ORM subquery.
>
> The following query is prepared in one part the program
> query = session.query(Taggable).filter ()
>
>
> Elswere I try to get the unique names associated with all previously
> selecte
Running much better this way...
>I think this will make the next release and adoption of the feature a
>lot easier.
Me too, many thanks for the quick turnaround!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlal
I am trying to do a select on the results an ORM subquery.
The following query is prepared in one part the program
query = session.query(Taggable).filter ()
Elswere I try to get the unique names associated with all previously
selected
Taggable obects.
names.select (exists ([names.c.id],
OK its False or None by default except on the Unicode type, where its
still set to True. Setting it to None on String means the dialect-
level flag takes effect, False or True overrides the dialect setting.
I think this will make the next release and adoption of the feature a
lot easier.
On 27/11/2007, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 27, 2007, at 11:30 AM, Yuri Pimenov wrote:
>
> >> Quote it.
>
> oh right, duh, let me answer post-coffee next time
>
> SQLite is the reason for the truncation on the dot, and I got both
> test cases (i.e. using sqlite and you
> the assert_unicode thing only happens with python SQL expressions,
>usually DDL is issued using textual SQL. if youre using a SQL
> expression for your DDL
The creates/drops are via Metadata.create_all() / .drop_all(), so perhaps
there's an expression in that path? Didn't trace it yet (as I tho
> also, what im considering doing, is having assert_unicode only be
> implicitly turned on for the Unicode type specifically. the engine-
> wide convert_unicode and String convert_unicode would not implicitly
> set the assert_unicode flag.
That makes more sense to me, and I would prefer it. The
also, what im considering doing, is having assert_unicode only be
implicitly turned on for the Unicode type specifically. the engine-
wide convert_unicode and String convert_unicode would not implicitly
set the assert_unicode flag. in this case you get the inconsistent
round trips.
On
On Nov 27, 2007, at 2:36 PM, Rick Morrison wrote:
> What's the point of the new 'assert_unicode' flag? It's causing
> failures with pymssql DDL (in my case CREATE / DROP)
>
> Is there a good reason to not only allow unicode, but to *enforce*
> it for DDL?
>
> I'd like to have one set of tabl
> default isolation mode settings usually dont need any changes. we
> dont have an official API for that yet, so you can apply it to all
> connections using a custom connect() function sent to create_engine,
> or you can try setting it individually as conn = session.connection();
> conn.connectio
What's the point of the new 'assert_unicode' flag? It's causing failures
with pymssql DDL (in my case CREATE / DROP)
Is there a good reason to not only allow unicode, but to *enforce* it for
DDL?
I'd like to have one set of tabledefs, prefererably in ASCII for DB
portability.
--~--~-~--~
On Nov 27, 2007, at 11:30 AM, Yuri Pimenov wrote:
>> Quote it.
oh right, duh, let me answer post-coffee next time
SQLite is the reason for the truncation on the dot, and I got both
test cases (i.e. using sqlite and you dont expect the dot, or using
dot-separated labels and you do expec
It may not help in your situation, but did you know that you can also
index the row with the Column instances themselves
Ie: row[table.c.column]
Simon
> -Original Message-
> From: sqlalchemy@googlegroups.com
> [mailto:[EMAIL PROTECTED] On Behalf Of Yuri Pimenov
> Sent: 27 November 2007
I've found 'use_labels' parameter in select(). Everything is good but
it uses _ as separator between table and column. That makes things
not so easy because it is common practice to use _ in table and column
names.
Why not to use . as separator?
My other blue sky dream is about ORM and unicode co
On Nov 27, 2007, at 11:18 AM, Jason R. Coombs wrote:
>
> This issue seems to be causing me some trouble as well. Using
> sqlalchemy-0.4.2dev_r3832, I'm getting the following error when
> attempting to flush my session:
>
>if not len(self._last_inserted_ids) or self._last_inserted_ids[0]
> i
This issue seems to be causing me some trouble as well. Using
sqlalchemy-0.4.2dev_r3832, I'm getting the following error when
attempting to flush my session:
if not len(self._last_inserted_ids) or self._last_inserted_ids[0]
is None:
AttributeError: 'MSSQLExecutionContext_pyodbc' object has n
On Nov 27, 2007, at 3:04 AM, icct wrote:
>
> Hi.
>
> Is there a way to make RowProxy use fully qualified column names like
> "table.column"
> as keys?
> Even if i explicitly label column with "as" in query, RowProxy chops
> off anything till last
> dot in label.
>
the reason for that is becaus
Hi.
Is there a way to make RowProxy use fully qualified column names like
"table.column"
as keys?
Even if i explicitly label column with "as" in query, RowProxy chops
off anything till last
dot in label.
--
Yuri Pimenov
--~--~-~--~~~---~--~~
You received this mes
21 matches
Mail list logo
