On Jul 15, 2009, at 5:03 PM, Kyle Schaffrick wrote:
>> >> 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__. __len__ is called if you implement __iter__ and you say list(obj), which is because the list() tries to optimize the activity by sizing itself appropriately first. > > >> 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(). well it *is* SQL count(). It just has an assumption as to *what* you want to count, and it counts the total number of rows that come from the thing you are selecting, hence it throws complex statements into a subquery. People actually want to count some specific column in some specific way and the fact that count() is present leads them to not consider exactly what it is they want to count. But its just so convenient for there to be a count() there, just for all the simple cases, that its difficult to justify taking it out totally. >> 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. > > U > 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). SQLObject and everyone else all hits the __len__ / __iter__ issue. if that didnt exist we'd almost certainly be using __len__(). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
