Can we agree on the suggested design?
Or does anyone think it needs to be incorporated into *list_display*?
On Wednesday, September 21, 2016 at 7:43:06 PM UTC+3, dor wrote:
>
> I recently suggested adding a *list_aggregates* member to ModelAdmin,
> along with a patch to match:
> https://code.djan
Mosson wrote:
>
> We have an implementation of both annotations in *list_display* and
> adding an aggregates for the entire list (which we call *list_summary*
> and what you are calling here *list_aggregates*) and there are a bunch of
> subtleties in the interaction due to Admin&#x
We have an implementation of both annotations in *list_display* and adding
an aggregates for the entire list (which we call *list_summary* and what
you are calling here *list_aggregates*) and there are a bunch of subtleties
in the interaction due to Admin's built in support for paginatio
I think I'm OK with `list_aggregates` because it implies a terminal
queryset method which really restricts the members used to create that
aggregation (the GROUP BY). Adding aggregates to existing list_display
would require something *else* to refine the group by using `values()`
How do you envision it interacting with ticket #14336 (annotations in
list_display)? Would we also need list_annotate? I'm a little sad every
time we add another customization point to the admin as I fear no end to
the complexity, but maybe I should just get over it.
https://code.djangoproject.
I recently suggested adding a *list_aggregates* member to ModelAdmin, along
with a patch to match:
https://code.djangoproject.com/ticket/27229
A core developer counter-suggested changing the design of list_display to
achieve the same;
What do you think?
--
You received this message because yo
I would love to see the aggregate classes (Sum, Avg, etc) take an
optional second parameter that becomes the value in a coalesce
statement in the resulting query. Basically, this would function a
lot like dict.get. Right now the only option is to resolve to None.
If, for instance, you could say
On Wed, Jan 21, 2009 at 9:01 AM, Ludvig Ericson wrote:
>
> On Jan 21, 2009, at 14:10, Russell Keith-Magee wrote:
> > Any opinions? Any other options that I may have missed?
>
> Sorry if I'm stating the obvious, but would it be
> impossible to error out if two aggregat
>> 1) Prevent joins at the query level. Keep track of the joins
>> that are being used for aggregates, and only allow one join.
>> This would mean killing a lot of queries that work correctly
>> right now, but would prevent the class of invalid queries.
>>
>>
On Jan 21, 2009, at 14:10, Russell Keith-Magee wrote:
> Any opinions? Any other options that I may have missed?
Sorry if I'm stating the obvious, but would it be
impossible to error out if two aggregates cause this
unexpected behavior?
I mean then I'd say raising an exception for
Hi all,
I've been looking at ticket #10060, The problem is caused by join
behavior in aggregates, but I'm uncertain about the best way to
address the problem.
Using the example from the ticket, the problem goes like this: You can
use double underscore notation for form joins in
Russ, thanks a lot for your work on this feature and for letting us track
the development on your git branch.
Regards
Ariel.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
ultiple Python versions co-exist fairly easily under
> Windows).
>
> I've opened ticket #10031 to track this known problem. If you find any
> other issues with aggregates, please open a ticket (or ask on the
> mailing list/IRC if you're unsure if the problem is usage or bug).
On Thu, Jan 15, 2009 at 6:57 AM, Ivan Sagalaev
wrote:
>
> Russell Keith-Magee wrote:
> > For those watching trunk, revision 9742 added aggregate support to
> > Django. (Yay!)
>
> Thank you all very much! This is big.
>
> >
> Tremendous thanks to Nicholas for writing this thing, and to Russ for
mak
Russell Keith-Magee wrote:
> For those watching trunk, revision 9742 added aggregate support to
> Django. (Yay!)
Thank you all very much! This is big.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
her issues with aggregates, please open a ticket (or ask on the
mailing list/IRC if you're unsure if the problem is usage or bug).
Lastly - some thank-yous. This commit wouldn't have been possible
without the assistance of many other people.
Nicolas Lara did some excellent work turning a spe
t; ...
>>>>> Kids.objects.annotate(Count('friends__toys'), Count('friens__toys',
>>>>> distinct=True))
>
>> while distinct would act on the select, or, even if we adapt it, it
>> would act inside all the Count objects.
>
> Ah - I
to allow the subqueries to occur only in some special
cases without the user knowing there is a subquery involved, and the
third is having a bit of both: allowing some syntax to specify
subqueries but also automatically making the subqueries when the use
case requires it.
In aggregate
x27; that we can use
> to evaluate potential solutions. It may not be possible to find a
> solution for every problem, but we won't know that until we have a
> list of real problems to work with.
>
> So, if you have an interesting use case for aggregates (i.e.,
> aggregate qu
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
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?
>
> Annotat
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?
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,
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
nt 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 e
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
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
real example with regards to this
> > I could put some up.)
>
> That's really what we're looking for. I would be highly surprised if
> aggregates weren't used for reporting purposes - the standing question
> is "what types of reports do people find interesting?"
&g
ive
> queries then standard ones.)
>
> -Alen
> (PS. if there is a need to give some real example with regards to this
> I could put some up.)
That's really what we're looking for. I would be highly surprised if
aggregates weren't used for reporting purposes - the stand
le to find a
> solution for every problem, but we won't know that until we have a
> list of real problems to work with.
>
> So, if you have an interesting use case for aggregates (i.e.,
> aggregate queries that you would like to make, but currently need to
> use raw SQL or a
d give us a set of concrete 'problems' that we can use
to evaluate potential solutions. It may not be possible to find a
solution for every problem, but we won't know that until we have a
list of real problems to work with.
So, if you have an interesting use case for aggregates (i.e.
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
doesn't currently return 'just values' - it
returns a list of values, notionally tied to object instances.
Top-level aggregates won't ever be a list, and instance-based
(annotated) aggregates will always be associated with an instance.
> I hadn't really considered this
On Tue, Mar 25, 2008 at 2:48 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Distinct can cover most use cases for this, but in general:
>
> MyModel.objects.filter(some_kind_of_manytomany__blah__blah__blah=X).select_related(some_kind_of_manytomany__blah).group_by(some_kind_of_manytomany__blah)
e provided some sample SQL. However, that wasn't the start
> point. Once upon a time, you had a problem you needed to solve: "I
> need to find all the MyTable objects that have more than one related
> OtherTable objects". Notice that this question doesn't use the phrase
t
> > patches like mine?
>
> Lets see if I can make myself clearer by using your example.
>
> You have provided some sample SQL. However, that wasn't the start
> point. Once upon a time, you had a problem you needed to solve: "I
> need to find all the MyTable obje
make myself clearer by using your example.
You have provided some sample SQL. However, that wasn't the start
point. Once upon a time, you had a problem you needed to solve: "I
need to find all the MyTable objects that have more than one related
OtherTable objects". Notice that thi
On Mon, Mar 24, 2008 at 4:23 AM, Winsley von Spee <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> perhaps I've just read over it, but how to you plan to handle not
> numeric types like datetime? In mysql you have to use something like
> "FROM_UNIXTIME(AVG(UNIX_TIMESTAMP(today))", but how should that be
A quick ping: I've written a small patch against qs-rf which might
facilitate the development of aggregates, and solve David Cramer's
problem of having to fork Django.
The idea is to allow for a custom QuerySet subclass to be used by
default everywhere, so if yo
l what the grouping should be from the filter. Maybe try some more
examples to see if group_by() is actually necessary. It could be that for
all or most of your cases, implicit grouping works fine.
Sorry -- I missed page 2. So GROUP BY and similar things will be
>
supported through an Aggregate
On Sun, Mar 23, 2008 at 12:23 PM, Winsley von Spee <[EMAIL PROTECTED]>
wrote:
> perhaps I've just read over it, but how to you plan to handle not
> numeric types like datetime? In mysql you have to use something like
> "FROM_UNIXTIME(AVG(UNIX_TIMESTAMP(today))", but how should that be
> handled in
Sorry -- I missed page 2. So GROUP BY and similar things will be
supported through an Aggregates base class?
On Mar 18, 6:36 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Wed, Mar 19, 2008 at 9:26 AM, Justin Fagnani
>
> <[EMAIL PROTECTED]> wrote:
> &
at hopefully we can be on the same page and not have duplicated
> > proposals and work. Hopefully the core devs can check this out after this
> > week.
>
> You may not have _all_ the core developers attention, but _some_ of
> them are listening - I'm definitely reading ev
Hey Honza,
On Tue, 2007-04-17 at 03:03 +0200, Honza Král wrote:
> On 4/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
> > [...]
> > > > btw. refactoring the queryset code is necessary for this to work, so
> > > > perhaps
On 4/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
> [...]
> > > btw. refactoring the queryset code is necessary for this to work, so
> > > perhaps we should focus our efforts there first. Maybe something will
> > > emerge fro
On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
[...]
> > btw. refactoring the queryset code is necessary for this to work, so
> > perhaps we should focus our efforts there first. Maybe something will
> > emerge from that that would help us decide.
>
> Granted. At one point, Malcolm
On 4/16/07, Honza Král <[EMAIL PROTECTED]> wrote:
> besides, Django's queryset is very SQL-centric so far
To a large extent, yes, but no in some very important ways.
Article.objects.all() isn't the least bit SQL, although the mapping to
SQL is obvious. Preserving the object flavor of the ORM is
ng like this
sooner or later. Reporting and (even this primitive) BI is very
lucrative business and customers want it.
but
> also because summary statistics for joined tables will require the use
> of __ syntax in the result dictionaries, which isn't as immediately
> expressive as al
ies, which isn't as immediately
expressive as aliased names.
- While your syntax is very good for generating groups and (aggregates
of those groups) on a single table, I don't see it extending well into
joins - especially filtering on joins. Using __sum__lte as you suggest
is a problem for f
sorry, forgot to include the group_by columns in the select clause:
> qset.values('field', 'field2', 'field3__sum', 'f4__count', ...) < = >
> SELECT field, field2, SUM(field3), count(f4) FROM some_table GROUP BY field,
> field2;
--~--~-~--~~~---~--~~
You received
me a list of dictionaries of
> object data that isn't a full object'?
from a technical view - YES, from user's view: NO
that should be two different things, only the same format of returned
data doesn't seem to be enough to merge these two functions
When the aggregates clause is
is already provided by the
values() filter? i.e., saying 'return me a list of dictionaries of
object data that isn't a full object'? When the aggregates clause is
in use, a GROUP BY over the selected fields is implied. If you don't
provide a values clause, then you want to GROUP
On 4/13/07, Honza Král <[EMAIL PROTECTED]> wrote:
> the queryset refactoring must (well, should) happen before aggregation
> support. After the refactoring, it should be relatively easy to put in
> the aggregations.
>
> see:
> http://code.djangoproject.com/ticket/3566
I didn't notice this ticket
7;s the status?
Many proposals have been made on this feature, but nothing has been
decided upon. For the record, here's my last attempt at a proposal:
http://groups.google.com/group/django-developers/msg/2f91fa217bc465bb
I'm _very_ keen to get aggregates into Django - it was one of the
the queryset refactoring must (well, should) happen before aggregation
support. After the refactoring, it should be relatively easy to put in
the aggregations.
see:
http://code.djangoproject.com/ticket/3566
http://groups.google.com/group/django-developers/browse_frm/thread/691da1d6e3b0661d/3e7aaad
I didn't see anything about aggregate support in
VersionOneFeatures[1], are people still hung up about the syntax, or
is anyone hacking on this? It's been mentioned a couple times since
PyCon, but what's the status?
[1] http://code.djangoproject.com/wiki/VersionOneFeatures
--~--~-~--~--
On 30/05/2006, at 4:43 PM, Shaun Cutts wrote:
>
> Ian,
>
> Thanks. Your code looks concise, but a bit mysterious (maybe it's
> the time
> of night). Is this a way to get extra events triggered in a db
> transaction,
> or is it just inside a single web request?
>
just inside a single web requ
Ian,
Thanks. Your code looks concise, but a bit mysterious (maybe it's the time
of night). Is this a way to get extra events triggered in a db transaction,
or is it just inside a single web request?
As far as I can tell, you don't seem to be insisting on having one
transaction; if you are, are y
Hi Shaun.
I've done something similar to this using the dispatcher.
in http://svn.zyons.python-hosting.com/trunk/zilbo/common/forum/
models.py (at the VERY bottom)
I use the signals to update summary tables .. I'm using pre_save..
but you should be able to get what you need with the post_sav
Hello,
I tried using @transaction.commit_on_success to insert an object whose
pieces are in (sub)tables.
Conceptually, this should all be part of one transaction. However,
django doesn't have the new id available, and so the operation fails
(it tries to use "null" for the foreign key in the subt
75 matches
Mail list logo
