Thanks both for the feedback. I think I'll just have to stay on top of my DAL calls :O)
Paul. On Feb 17, 7:15 pm, Marin Pranjic <marin.pran...@gmail.com> wrote: > It's because of pythons limitations in overloading operators. > You can change behavior of &, |, ~ in python, but cannot change and, or, > not. > > On Thu, Feb 17, 2011 at 7:00 PM, Paul Gerrard > <p...@gerrardconsulting.com>wrote: > > > > > > > > > On more than one occasion, I've been caught out by a slip in my select > > statements. If you use 'and' rather than '&' to combine criteria for a > > select you get different results. In the first case, (and) the code > > returns a single record, regardless of the values of the critieria > > used for the selection. In the second case (&) I get the correct > > record depending on the value of termkey. > > > # this doesn't work > > # > > glossary=db((db.glossaryterms.termkey==termkey) and > > (db.glossaryterms.org_id==session.org_id)).select() > > # > > # this does work > > glossary=db((db.glossaryterms.termkey==termkey) & > > (db.glossaryterms.org_id==session.org_id)).select() > > > My question is: should using 'and' work at all or is it precluded as a > > keyword in queries? As it is I've lost hours trying to figure out the > > problem. > > > If 'and' should work - there's a bug in DAL I think. > > If 'and' should not work, then it would be really helpful if the DAL > > rejected with a runtime failure message so it doesn't waste a lot of > > time.
