On Wed, 15 Jul 2009 10:35:24 -0400 "Michael Bayer" <mike...@zzzcomputing.com> wrote: > > Kyle Schaffrick wrote: > > > > On Mon, 13 Jul 2009 19:18:39 -0400 > > "Michael Bayer" <mike...@zzzcomputing.com> wrote: > >> > >> Brad Wells wrote: > >> > > >> > Is it possible to perform a query.count() on a query with a > >> > labeled column expression without count() adding the subselect? > >> > I need to filter on the value of the expression and get a count > >> > for a paged view. > >> > >> although reading the docs to query.count(), its pretty clear as > >> far as querying mapped entities vs. column expressions. I think > >> it might just need very clear documentation that, for counting > >> anything more complex than query(Foo).filter().count(), you should > >> be using column expressions. > >> > > > > Idea: query.count() could be superseded by len(query) so that it > > clearly suggests the intended use case of "how many things are > > returned by this query" instead of the wierd SQL concept of > > count(), which should be served by column expressions. It also > > nicely aligns it with other Python collection-y things. > > len(query) forces us to play games with the __iter__ method on query > such that it can't be a real iterator. >
Hmm, I thought there was a __len__ magic method, such that len(something) is the same as something.__len__(), when the latter is overridden in something's class. I didn't realize it interacted with __iter__. > Also, the theme here is query.count() often does not do what you > expect. making it invisible just makes that fact harder to realize. I was suggesting it as a continuation of your observation above that any use of that method, more complex than query(Foo).filter().count(), is probably not going to do what you expect, implying that .count() should really only be used for asking "how much stuff comes out of this query". The thought was that by not calling it .count(), people won't expect it to behave like SQL COUNT(). > as far as "weird SQL concepts", SQLA's orm is intentionally > SQL-specific. hence it has other "weird" things like join(), > outerjoin(), group_by(), having(), etc. Understood, and I agree with and appreciate that philosophy. But if query.count() does not do what you expect in the SQL sense, and should probably only be used in the sense of Python's len(), then my intuition is that it should not be called query.count(), it should be called len(query) :) Anyway, I'll digress, just wanted to clarify my thought process there. I don't disparage directly exposing the power of SQL, but indeed, the API that mimicks SQL names should do the obvious SQL-y things, and if it doesn't, overloading the names might lead to confusion (and seemingly does in this case). -Kyle --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
