>
> Providing a way to count different fields is a good idea, and the
> approach you've described looks good to me. I just wanted to make sure
> that the simplest case (count all instances) is trivial (i.e., doesn't
> require explicit naming of the PK field).
>
This is fixed in the latest revisio
On Fri, May 9, 2008 at 12:46 AM, Russell Keith-Magee <[EMAIL PROTECTED]>
wrote:
> As a hint to the community - one of the best suggestions we can have
> at this stage of the project is a set of interesting problems to
> solve. This would give us a set of concrete 'problems' that we can use
> to ev
lished more than 10
> > books this year
> > (Query over the reverse direction of a FK, with a filter on the related
> > object)
>
> >>> Publisher.objects.all().annotate(num_books=Count('book__id')).filter(num_books__gt=10,
> >>> book__price__lt=50)
>
ished more than 10
> books this year
> (Query over the reverse direction of a FK, with a filter on the related
> object)
>
>>> Publisher.objects.all().annotate(num_books=Count('book__id')).filter(num_books__gt=10,
>>> book__price__lt=50)
So far so good. Though filter() is not yet i
jango-developers@googlegroups.com
Subject: Re: On aggregates
Hi,
> DISTINCT and GROUP BY are both annotating the results. Taking many
> rows, and turning them into a single row based on a key. DISTINCT would
> be the same as GROUP BY every, field, in, the, select.
Mathematically true, but I
Hi,
> DISTINCT and GROUP BY are both annotating the results. Taking many
> rows, and turning them into a single row based on a key. DISTINCT would
> be the same as GROUP BY every, field, in, the, select.
Mathematically true, but I think having two separate concepts makes the code
easier to read
David Cramer said the following:
> DISTINCT and GROUP BY are both annotating the results. Taking many rows,
> and turning them into a single row based on a key. DISTINCT would be the
> same as GROUP BY every, field, in, the, select.
But forcing people to group by every field they select in orde
Hi, David,
even if annotate() actually _could_ replace distinct()... Wouldn't you
like to keep the syntactic sugar around? not to mention the backward
compatibility... Also, for users looking for the simple distinct
behaviour, it is very complex and unnecessary having to think of it in
terms of gr
DISTINCT and GROUP BY are both annotating the results. Taking many rows, and
turning them into a single row based on a key. DISTINCT would be the same as
GROUP BY every, field, in, the, select.
On Tue, May 13, 2008 at 10:29 AM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> David Cramer said the fol
David Cramer said the following:
> If that is the case, then annotate would replace GROUP BY, and should
> also be able to replace distinct().
Why would replacing distinct() ever make any sense?
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message bec
That's much more clear than what I had been reading.
If that is the case, then annotate would replace GROUP BY, and should
also be able to replace distinct().
On May 12, 9:27 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Tue, May 13, 2008 at 12:01 PM, David Cramer <[EMAIL PROTECTED]>
Thanks for the sugestion Alex,
I will do that.
Also, Im glad to see you are following the updates closely :)
On Mon, May 12, 2008 at 10:26 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Hey, just saw the update, and my suggestions would be, instead of
> using round() figure out how many
On Tue, May 13, 2008 at 12:01 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> I realize how the aggregates work, but if annotate is just for
> aggregates, then remove it as a standalone method. If it's not, then
> it should solve all the problems with one blow.
Pardon?
Annotate and aggregate
I realize how the aggregates work, but if annotate is just for
aggregates, then remove it as a standalone method. If it's not, then
it should solve all the problems with one blow.
On May 12, 4:37 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, May 12, 2008 at 10:50 PM, David Cramer
Hey, just saw the update, and my suggestions would be, instead of
using round() figure out how many places of congruency there are
between the backends and use the ... syntax instead.
For example if:
pgsql: 37.4697
sqlite: 37.4701
mysql: 37.47
just print out
37.4...
On May 12, 6:37 pm, "Russell
On Mon, May 12, 2008 at 10:50 PM, 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,
I don't mean to be rude, David, but the difference between
My assumption was annotate was the equiv of GROUP BY, which is what
annotate sounds like :)
If that's the case, I believe annotate should also replace distinct(),
as it is very very similar in its use-cases.
On May 12, 12:05 pm, koenb <[EMAIL PROTECTED]> wrote:
> If I understand it correctly, th
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 aggr
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 i
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
> re
If I understand correctely you are trying to do something like:
"Give me the and the sum of the financial transactions of type 'M'
between a given date range for each contract ordered by id and short
title)"
Is that the kind of aggregate you needed?
This could be expressed as:
c =
Contract.obj
It is not possible yet. But it will after the first stage (basic
stuff) is working correctely.
A great help would be, as Russell suggests, providing some complex
cases of aggregates (the actual plain english problems that want to be
solved with aggregates) so we can see if the proposed functionali
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 int
Here is one of my current real-world, common, examples:
Monthly maintenance costs - Report
custom_sql_query = """
SELECT c.id, p.short_title, sum(f.amount)
FROM manager_contract c, manager_financialtransaction f,
manager_property p
WHERE f.pub_date >= '%s' and f.p
On Fri, May 9, 2008 at 3:58 PM, Alen Ribic <[EMAIL PROTECTED]> wrote:
>
> Reporting is quite common in my area of work at the moment and most of
> the time some form of aggregation is required to build meaningful
> reports. (For such case I have substantially more custom/native
> queries then stan
Reporting is quite common in my area of work at the moment and most of
the time some form of aggregation is required to build meaningful
reports. (For such case I have substantially more custom/native
queries then standard ones.)
-Alen
(PS. if there is a need to give some real example with regard
On Fri, May 9, 2008 at 5:38 AM, Nicolas E. Lara G.
<[EMAIL PROTECTED]> wrote:
>
> Currently there is support for both aggregate and annotate on the
> simplest level. Some tests might be found under tests/modeltests/
> aggregation/ of the current state of the project. They can probably do
> as docu
And a second question, does filtering on an annotated field work, for
example:
Tag.objects.all().annotate(num_articles=Count('articles')).filter(num_articles__gt=2)
which return all tags who have more than 2 articles.
On May 8, 4:51 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I haven't h
I haven't had a ton of time to look over everything(just read the
tests so far), but why did you choose to return things as decimals in
place of a float?
On May 8, 4:38 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]> wrote:
> For those that are interested the aggregation project is hosted
> inhttp:
For those that are interested the aggregation project is hosted in
http://code.google.com/p/django-aggregation/
The code is basically an up to date copy of trunk patched with the
aggregation support and the relevant tests and doc.
Currently there is support for both aggregate and annotate on the
30 matches
Mail list logo
