If I understand it correctly, the aggregate and annotate ideas are result driven, not by the SQL that might be involved (which should indeed be entirely hidden). Aggregate normally gives one result, annotate gives you a bunch of objects, but with extra information PER object (normally from an aggregate on a foreign table).
On 12 mei, 16:50, David Cramer <[EMAIL PROTECTED]> wrote: > What is the difference between annotate and aggregate? They seem like > they'd do the same thing, except annotate sounds like it should be > doing GROUP BY, which, if that's the case, then this goes against the > very reasoning which a group_by or something similar should not be > used. The logic in the implied filters should be enough to determine > if you need to use a GROUP BY or a WHERE, or honestly, even a DISTINCT > (as I discussed in IRC the other day, DISTINCT is just another > approach to grouping, and should be dropped if we won't support GROUP > BY directly). > > On May 10, 6:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > > On Sat, May 10, 2008 at 2:37 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > The choice of using Decimal was not mine but that of the modules that > > > connect to the backends (postgres in this case), and this is one of > > > the problems I am facing right now. Different backends return the > > > results in different formats (Postgres: Decimal, SQLite: float... etc) > > > I am looking into a way of normalizing the results to the same format. > > > This is something we're going to want to normalize, and as Alex noted, > > floats would make a lot more sense. > > > > The issue of the datastructure that represents the results is only one > > > part of the problem. Due to the inner representation of numbers and > > > other factors of the different backends, the numeric results might be > > > different, for example, postgres might return 34.7321987 while sqlite > > > returns something like 34.732211 (rounding differentely the results). > > > Keep in mind that there are already a few places in the tests where we > > have to deal with inexact floating point references. The easy solution > > is modify the doctest to only print n decimal places, where n is > > enough places to check the test case, but won't contain any floating > > point ambiguity (in your case, check for 34.73 or 34.732) > > > Yours, > > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
