theoretically - this might make a+b+c+d look like a+(b+(c+d)). Which
isn't that bad, except that SA does not level-indent parenthesised
expressions, and the sql is going to look like lisp program... but
yes, u're right, SA relies on some python precedence and
associativity being same as SQL ones. which may or may not be ok.
as one can put brackets (a+b)+(c+d) where one needs explicitly, maybe
this would only be applicable to SA-generated things, like implicit
joins.
But then again, if just for readability, indenting by level the
parenthesises and subqueries helps much much much more. i had patch
about this long ago but it doesnot work anymore... sigh.
On Wednesday 28 January 2009 01:14:16 Jon Nelson wrote:
I recently ran into an issue. Is it a bug? No. However, it made my
brain hurt for a little bit until I remembered the SQL precedence
rules for AND and OR.
The operator precedence of AND and OR is known (AND takes
precedence). However, it can make humans hurt their brains a bit to
see SQL without (perhaps unnecessary) parens, explicitly noting the
desired order of operation. Perhaps a suggestion might be to always
use parens?
Approx. line 2168 of sql/expression.py:
if self.group and self.operator is not against and
operators.is_precedent(self.operator, against):
What would the harm be in removing the final test (and
operators.is_predecent...) ?
It seems to me that SQLAlchemy might group things a bit more
explicitly instead of relying on the precedence rules. Are there
database which have precedence rules that are not the same as
others (or are buggy)?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@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=en
-~--~~~~--~~--~--~---
