On Nov 21, 2009, at 1:19 PM, Michael Bayer wrote:
>
> Here is entirely idiomatic SQLAlchemy code which approximates the types of
> constructs your code snippets below are using - it places both the Query
> object into a NOT IN, as well as the select() construct generated by
> Query.subquery() within NOT IN, and generates valid SQL, including against
> the MySQL dialect. So I cannot reproduce your issue, going back to version
> 0.5.3.
Reproduced with 0.5.2. Here is the CHANGES note in 0.5.3, where the feature
was first added:
- Query now implements __clause_element__() which produces
its selectable, which means a Query instance can be accepted
in many SQL expressions, including col.in_(query),
union(query1, query2), select([foo]).select_from(query),
etc.
Here is another feature added in 0.5.3 which allows subquery() to be used in a
scalar context without the need to call "as_scalar()"
- An alias() of a select() will convert to a "scalar subquery"
when used in an unambiguously scalar context, i.e. it's used
in a comparison operation. This applies to
the ORM when using query.subquery() as well.
This would strongly suggest your issues are specific to the usage of features
which were not yet introduced in the version of SQLAlchemy you're using.
Current version of SQLA is now 0.5.6 - 0.5.2 is 10 months out of date. Please
confirm your issue is resolved via upgrade.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=.
