Also I believe group by shouldn't happen on every column unless explicit. By
default it should group on primary key.
-Original Message-
From: Yuri Baburov <[EMAIL PROTECTED]>
Sent: Thursday, May 01, 2008 1:53 PM
To: django-developers@googlegroups.com
Subject: Re: Aggregate Support to the
If annotate is equivilent to group by thenn ordering or seperation shouldn't
matter. In my opinion it should function just like any other filtering and just
merge together. Keep in mind I haven't read about the change to filter with
qs-rf yet.
-Original Message-
From: Nicolas Lara <[EM
+1
I've always felt that there must be a way to do this that I was just
overlooking.
Thanks,
Eric Florenzano
On May 2, 4:54 pm, "Graham King" <[EMAIL PROTECTED]> wrote:
> I have just submitted a patch / ticket to allow loadata to remove
> objects that are in the database but not in the fixture
I have just submitted a patch / ticket to allow loadata to remove
objects that are in the database but not in the fixture. It has docs
and tests.
http://code.djangoproject.com/ticket/7159
This means loadata can now make an app in a database exactly match
the app in the fixture. We use this to
Jean-François wrote:
> Oops... I haven't thought to trace connect/disconnect operation to the
> database only commit/rollback.
> Now, I have a better understanding of the underlaying model. I suspect
> that open a database connection then closing it for each request may
> be a fairly expensive ope
Hi guys
Following up on a previsous discussion:
http://groups.google.com/group/django-developers/browse_thread/thread/4c7b2ce86bcd990e/3731676c2134ea63
I've submitted a (rought) patch:
http://code.djangoproject.com/ticket/7158
Fell free to comment, improve etc.
-
aD
--~--~-~--~~---
I am not sure I agree with you on this. Since the succesive calls to
aggregate/annotate would actually be constructing the elements for the
final query in non ordered datastructures I think the order in which
different elements are inserted to the aggregation should not matter.
The values modifier
> It's probably
> not a good idea to assume either point of view.
I agree
> I wonder if aggregate functions on the quesyset's model should even be
> allowed in annotate(). I can't think of a case that makes sense. That
> restriction would certainly get rid of some ambiguity.
This is a solution
At the moment, it doesn't seem that a developers can do pre-save/post-
save work cleanly when dealing with Forms in NewForms Admin using
django.newforms.models.ModelForm.
For instance, if I'd like to send a notification email to a client
once a form has been submitted for the first time (add_view)
On 2 mai, 10:55, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Jean-François wrote:
> > My question was not really specific to any database backend (aggree
> > that probably all database system, including Rdb can start a
> > transaction implicitly, inclugind Rdb). But as I have noticed that a
> > m
Jean-François wrote:
> My question was not really specific to any database backend (aggree
> that probably all database system, including Rdb can start a
> transaction implicitly, inclugind Rdb). But as I have noticed that a
> method start_transaction_sql() exist I have expect that this method
> w
Ivan,
Thanks for our reply.
On 2 mai, 09:53, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Hello! I'll try to answer as much as I can.
>
> Jean-François wrote:
> > - can Django run in a cluster environnement (OpenVMS has a "shared
> > everything" cluster design) , meaning running simultaneous Django
Hello! I'll try to answer as much as I can.
Jean-François wrote:
> - can Django run in a cluster environnement (OpenVMS has a "shared
> everything" cluster design) , meaning running simultaneous Django
> server on different systems, so in different processes, or it is
> mandatory to run in a one-
13 matches
Mail list logo
