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-
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
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
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
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)
> 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
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
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
--~--~-~--~~---
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
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
+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
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
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
13 matches
Mail list logo
