On Nov 9, 2008, at 9:39 AM, Michael Bayer wrote:
> > > On Nov 9, 2008, at 4:46 AM, Cito wrote: > >> >> On 8 Nov., 22:03, Michael Bayer <[EMAIL PROTECTED]> wrote: >>> oh sorry, also count() is meant to count instances of a single kind >>> of >>> object. So in fact you should be saying: >>> >>> session.query(UserRss).join(Rss, item).count() >> >> This question is actually coming from the TurboGears group. The >> problem here is that our pagination mechanism takes an existing query >> and checks its result size with count(). I.e. we have no influence on >> the actual query, we just assume that if you can get all() or slices >> from the query that you can also count() its results. This had worked >> all the time up to 0.4.8, but with 0.5 it doesn't work any more. in the latest trunk r5269 I have overhauled query.count() to properly support multiple entity and column-oriented ORM queries. Your use case will now pass, but be aware that it now takes into account the full list of entities queried. In 0.4, this behavior was broken as it would only use the first entity, and silently ignore the rest. This means that a query such as query(A, B).count() with no JOIN or joining criterion will return the count of the cartesian product of A*B. A query such as query(func.count(A.somecol)).count() will return a value of one, since an aggregate function returns one row. None of this is supported at all in 0.4 and was previously not supported in 0.5. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
