If you're interested in performance, would it not also be wise to
issue a LIMIT 1 at the end of the query if possible? I believe SELECT
1 will just return N 1s and the RDBMS will not stop searching simply
because it found it. There are also some tickets to make checking the
existence of a filter r
This post may be better suited for the django-users list.
This list is for the discussion of the development of django itself,
not apps that use django.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django devel
Thanks Michael and George, exactly what I needed to know.
--Simon
--~--~-~--~~~---~--~~
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
Hi all,
The django website is choking on
http://www.djangoproject.com/documentation/models/
It's getting an internal server error, so it looks like a glitch in
this page's generation somewhere.
I'm pinging this, since there's been at least 3 duplicates of it, so
people are missing this page. C
On Sun, Aug 12, 2007 at 09:20:06AM -0400, George Vilches wrote:
> Something that I found a little irksome while working on this is that
> the DatabaseWrapper class for each backend doesn't inherit from some
> logical parent. I know that all the db-specific functionality is
> wrapped by these cl
Hello everybody.
A few month ago I did an own comments app, because the application
included with django doesn't have all the features I needed but a lot
of stuff I don't need. This one has a very simple base model, is
extensible and it uses the new forms framework. I'm planing to add
more featur
Don't see no harm in adding the close() hook, but as mr. Batchelder
said, I'd say it's the wrong thing to do.
If the connections really are dangling, I'd say there's a much larger
issue to deal with.
Sincerely,
Ludvig Ericson
On Aug 11, 1:57 am, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> This
Simon Greenhill wrote:
> Hi all,
>
> I'm trying to work out if Ticket #5030 is good to go or not.
> Basically, when save() is called on a model, django does a SELECT
> COUNT(*)... query to check that the primary key is good.
>
> However, SELECT 1... is apparently quite a bit faster in many
> cir
Hi,
On 8/12/07, Simon Greenhill <[EMAIL PROTECTED]> wrote:
> I'm trying to work out if Ticket #5030 is good to go or not.
> Basically, when save() is called on a model, django does a SELECT
> COUNT(*)... query to check that the primary key is good.
>
> However, SELECT 1... is apparently quite a b
I'm splitting this conversation off from the other conversation on SQL
logging, because I think that topic has merits all its own, and this one
has more to discuss and slightly more possibility for
backwards-incompatibility. I don't want to pork barrel this issue in
with a perfectly legitimat
Russell Keith-Magee wrote:
> I would suggest approaching this problem at lower than that -
> installing a filter at the level of the database cursor that diverts
> queries away from the actual database, and into a store. That way, if
> you run the code 'Author.objects.all()' , the backend will ge
On Sun, 2007-08-12 at 13:28 +0200, Andreas Stuhlmüller wrote:
[...]
> Once the SoC final evaluation is over (Mon, August 20th), it will be a
> lot easier (=possible) for me to work together with other people and
> to accept code contributions. This strikes me a little strange since
> SoC is suppos
On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote:
> Here is my suggestion: the current forms from model or instance are
> great but you often need a custom form, what about an extra-argument
> to the collection (better because I already need a form in the
> collection in order to return a creati
Hi all,
I'm trying to work out if Ticket #5030 is good to go or not.
Basically, when save() is called on a model, django does a SELECT
COUNT(*)... query to check that the primary key is good.
However, SELECT 1... is apparently quite a bit faster in many
circumstances, and we should use it if we
14 matches
Mail list logo