Thanks very much for your help! We'll plan to use a workaround now and
revisit the issue when 1.2 comes out.
There are a couple subtleties that may be of interest. Compiling to 0 or 1
has the effect of removing all syntactic references to the original
expression from the query. This is
On Thursday, June 30, 2016 at 3:38:08 PM UTC-4, Mike Bayer wrote:
>
>
> that's already there, in the form of the Python warnings filter.
> people keep asking about this and it should be in the FAQ.
>
>
Oh that's right - you can set warnings to raise.
--
You received this message because
On 06/30/2016 02:15 PM, Jonathan Vanasco wrote:
On Thursday, June 30, 2016 at 10:17:34 AM UTC-4, Mike Bayer wrote:
So it seems clear that probably for 1.2 we will need to add a
comprehensive layer of being able to change what "IN" does, the choices
being "raise", "simple-false",
On Thursday, June 30, 2016 at 10:17:34 AM UTC-4, Mike Bayer wrote:
> So it seems clear that probably for 1.2 we will need to add a
> comprehensive layer of being able to change what "IN" does, the choices
> being "raise", "simple-false", "column-false", and probably some others,
> and for
On 06/30/2016 08:08 AM, Shivaram Lingamneni wrote:
We're working with a codebase that uses SQLAlchemy 1.0.12 to talk to
MySQL 5.5. Periodically, we have issues with empty IN clauses.
Specifically, we have queries that look like
`MyTable.my_column.in_(my_sequence)`. When `my_sequence` is empty,
We're working with a codebase that uses SQLAlchemy 1.0.12 to talk to MySQL
5.5. Periodically, we have issues with empty IN clauses. Specifically, we
have queries that look like `MyTable.my_column.in_(my_sequence)`. When
`my_sequence` is empty, SQLAlchemy compiles this to `my_table.my_column <>
