The fix works great. Thanks for the quick response and a great project. And congrats on the 0.1.1 release - from what I can gather the project is getting a good early reception and building momentum.
Rick
On 2/22/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
oh thats small.."func" already has an "in_", its just the
determination of the "type" of the _expression_ was looking at the "in"
list which doesnt have a "type" attribute. I changed it so the
"func" side of the equation determines the type, rev 1020.
btw, the type of the _expression_ below is just NullTypeEngine type.
if you wanted the real type to be involved, youd say:
sql.func.substring (enatttr.c.val, 4, 7, type=types.String).in_(p1, p2)
On Feb 22, 2006, at 8:13 PM, Rick Morrision wrote:
> I'm having trouble with a construct like:
>
> SELECT fname FROM names WHERE SUBSTRING(tel, 4, 7) IN ('5551212',
> '4443333')
>
> The construct:
>
> sql.func.substring(entattr.c.val,4,7).in_(p1, p2)
>
> throws an error.
>
> I've looked into creating a freestanding in_ function in sql.py,
> which is messy -- looks like one can't prevent someone from using
> multiple clauses on the left side of the IN (which would be invalid
> SQL), and into extending the Function() class with an .in_
> function, which so far has been inscrutable to me.
>
> Can anyone suggest a different construct, or how to attack that
> Function() class?
>
> Thx,
> Rick
>
