On Aug 16, 2013, at 9:40 AM, Jeff Dairiki <dair...@dairiki.org> wrote:
> > Thank you for the quick response (as always), Mike. > > But I'm still fuddled. > > Okay, so I can customize how __invert__(), __and__() and __or__() (all > the operations that evaluate their arguments in a boolean context) get > compiled. (I think that's what you're pointing me at, right?) > (Really cool, by the way!) > > But that still won't "fix" my original example where .filter(MyTable.ynbool) > produces "SELECT ... WHERE MyTable.ynbool;", since none of those operations > are involved. > > I've tried adding a custom comparator_factory.__nonzero__() operator > to my type, but that didn't seem to work. (Though it's possible I did > it wrong.) Should it have? > > Anyhow, this is not even close to the highest priority item in my > queue, ATM. (So it shouldn't be for you either, unless there's an > easy solution that I'm not seeing.) I will look into it further at > some point in the future. oh right, this is more of a hybrid attributes thing. Yes, at the moment filter()/where() doesn't have an implicit operation that it runs on SQL expressions - we coerce from non-SQL elements to SQL but that's it. something more elaborate would have to be added into the SQL expression system at the point at which boolean expressions are expected (WHERE, HAVING, ?) and there'd need to be some coerce_to_bool type of thing that you could hook into. We have this issue with regular boolean types as well, SQL Server doesn't like "WHERE 1" for example.
signature.asc
Description: Message signed with OpenPGP using GPGMail
