On Tue, Feb 17, 2009 at 7:49 PM, Malcolm Tredinnick
wrote:
> I'd be somewhat against this, I think. It's *very* easy to reuse
> querysets and inadvertently cause extra database queries. Unless you're
> using really huge querysets, the memory usage is not going to kill you.
> Pulling back the huge
On Tue, 2009-02-17 at 19:25 -0600, Jeremy Dunck wrote:
> On Tue, Feb 17, 2009 at 7:13 PM, Malcolm Tredinnick
> wrote:
> ...
> >> if settings.DEBUG and self.prior_iteration:
> >>warnings.warn("dope!")
> >
> > This certainly sounds reasonable and doable today without any real
> > overhead. Go a
Sorry... will do next time
On Feb 17, 8:09 pm, Malcolm Tredinnick
wrote:
> On Tue, 2009-02-17 at 16:44 -0800, Tasmania wrote:
> > Hi there,
> > I have one single application that has building up functionalities so
> > views.py has grown and it's getting big. The application is running
> > fast,
Thanks Alex!
On Feb 17, 8:08 pm, Alex Gaynor wrote:
> On Tue, Feb 17, 2009 at 7:44 PM, Tasmania wrote:
>
> > Hi there,
> > I have one single application that has building up functionalities so
> > views.py has grown and it's getting big. The application is running
> > fast, but I'd like to part
On Tue, Feb 17, 2009 at 7:13 PM, Malcolm Tredinnick
wrote:
...
>> if settings.DEBUG and self.prior_iteration:
>>warnings.warn("dope!")
>
> This certainly sounds reasonable and doable today without any real
> overhead. Go ahead and make a patch/ticket.
OK.
Do you think there should be a Perf
On Tue, Feb 17, 2009 at 5:54 PM, Malcolm Tredinnick
wrote:
>
> Hi Ian,
>
> On Tue, 2009-02-17 at 16:05 -0700, Ian Kelly wrote:
> [...]
>> The solution that I'm proposing is to use the extra select expression
>> itself in the group by, rather than the alias. This passes the tests
>> across all fo
On Tue, 2009-02-17 at 18:57 -0600, Jeremy Dunck wrote:
> On Tue, Feb 17, 2009 at 6:49 PM, Malcolm Tredinnick
> wrote:
> ...
> > I'd be somewhat against this, I think. It's *very* easy to reuse
> > querysets and inadvertently cause extra database queries.
> ...
> > we're trading memory
> > usage f
On Tue, 2009-02-17 at 16:44 -0800, Tasmania wrote:
> Hi there,
> I have one single application that has building up functionalities so
> views.py has grown and it's getting big. The application is running
> fast, but I'd like to partitionate views.py (i.e. putting some
> functions in a different f
On Tue, Feb 17, 2009 at 7:44 PM, Tasmania wrote:
>
> Hi there,
> I have one single application that has building up functionalities so
> views.py has grown and it's getting big. The application is running
> fast, but I'd like to partitionate views.py (i.e. putting some
> functions in a different
Hi there,
I have one single application that has building up functionalities so
views.py has grown and it's getting big. The application is running
fast, but I'd like to partitionate views.py (i.e. putting some
functions in a different file, etc) can I do that in Django?
Thanks!
T
--~--~---
On Tue, Feb 17, 2009 at 6:49 PM, Malcolm Tredinnick
wrote:
...
> I'd be somewhat against this, I think. It's *very* easy to reuse
> querysets and inadvertently cause extra database queries.
...
> we're trading memory
> usage for speed and ease of use (and providing a way to improve the
> former i
One of the desired but lacking a champion features for 1.1 ([ORM-09],
#3182) has been updated to work with r9844 with tests and docs, and
improved as per the last comments on the ticket.
I think this one is ready to go in, but I didn't want to set the
ticket "ready for checkin" until someone else
Hi Ian,
On Tue, 2009-02-17 at 16:05 -0700, Ian Kelly wrote:
[...]
> The solution that I'm proposing is to use the extra select expression
> itself in the group by, rather than the alias. This passes the tests
> across all four included backends, and seems to work in general as
> long as the expr
On Tue, 2009-02-17 at 15:20 -0600, Jeremy Dunck wrote:
> On Tue, Feb 17, 2009 at 3:15 PM, Jeremy Dunck wrote:
> ...
> > {% for question in poll.questions.all.iterator %}
> > works just fine.
> >
>
> OK, last one from me.
>
> As a 2.0 wish, I'd like to make .iterator the default behavior, and
>
On Tue, 2009-02-17 at 02:58 -0800, Waldemar Kornewald wrote:
> No comments on the more efficient perms/contenttypes implementation?
If you were hoping for something from me, I don't have any time to think
about it. I'm not in the business of predicting the future in a general
sense, beyond things
On Tue, Feb 17, 2009 at 5:01 PM, Russell Keith-Magee
wrote:
> Out of interest - where does Oracle fall on this one? Can you use
> aliases in a HAVING or ORDER BY?
Oracle only allows aliases in the ORDER BY clause.
>
>> If there are no concerns or potential gotchas with this approach, then
>> I'
On Wed, Feb 18, 2009 at 8:05 AM, Ian Kelly wrote:
>
> I'd like to request some extra sets of eyes for the patch in ticket #10290.
>
> The summary: from r9838 on, I'm getting aggregation_regress test
> failures in Oracle, apparently because annotations with extra selects
> are adding the extra sel
On Tue, Feb 17, 2009 at 6:05 PM, Ian Kelly wrote:
>
> I'd like to request some extra sets of eyes for the patch in ticket #10290.
>
> The summary: from r9838 on, I'm getting aggregation_regress test
> failures in Oracle, apparently because annotations with extra selects
> are adding the extra sel
I'd like to request some extra sets of eyes for the patch in ticket #10290.
The summary: from r9838 on, I'm getting aggregation_regress test
failures in Oracle, apparently because annotations with extra selects
are adding the extra select aliases into the group by list. This
produces invalid SQL
On Tue, Feb 17, 2009 at 3:00 PM, Jeremy Dunck wrote:
>
> On Tue, Feb 17, 2009 at 3:52 PM, James Bennett wrote:
>>
>> On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran wrote:
>>> Today i read this article and was wondering whether django orm is
>>> really that bad.
>>>
>>> http://dayhacker.blogspot.
On Tue, Feb 17, 2009 at 3:52 PM, James Bennett wrote:
>
> On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran wrote:
>> Today i read this article and was wondering whether django orm is
>> really that bad.
>>
>> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
>
> Well
On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran wrote:
> Today i read this article and was wondering whether django orm is
> really that bad.
>
> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
Well, it's obligatory for me first to say "wow, Blogger sucks", since
On Tue, Feb 17, 2009 at 3:15 PM, Jeremy Dunck wrote:
...
> {% for question in poll.questions.all.iterator %}
> works just fine.
>
OK, last one from me.
As a 2.0 wish, I'd like to make .iterator the default behavior, and
the cached-version a special case. I realize this point is quite
debatable
On Tue, Feb 17, 2009 at 2:11 PM, Alex Gaynor wrote:
...
>
> Neither is completely correct ;). Both do chunked reads from the
> DB(__iter__ using iterator for getting the data), however __iter__ also
> caches them, so if you reiterate you don't do a second db query, whereas
> iterator doesn't cac
On Tue, Feb 17, 2009 at 3:12 PM, Jeremy Dunck wrote:
> Even so, it seems like it'd be useful to have a built-in filter which
> uses iter(object)?
>
> {% for question in poll.questions.all()|iterate %}
Ugh.
Sorry, I'm an idiot.
{% for question in poll.questions.all.iterator %}
works just fine.
On Tue, Feb 17, 2009 at 1:50 PM, Ian Kelly wrote:
>
> On Tue, Feb 17, 2009 at 7:40 AM, M N Islam Shihan
> wrote:
> >
> > Hi,
> >
> > Please go through the comments of the blog post you are referring and
> you'll
> > understand why, how and where to use the django ORM.
> >
> > Regards,
> > Shihan
On Tue, Feb 17, 2009 at 7:40 AM, M N Islam Shihan wrote:
>
> Hi,
>
> Please go through the comments of the blog post you are referring and you'll
> understand why, how and where to use the django ORM.
>
> Regards,
> Shihan
Something I've just noticed here. One of the comments links to the
docum
Hi,
Please go through the comments of the blog post you are referring and you'll
understand why, how and where to use the django ORM.
Regards,
Shihan
- Original Message -
From: "NitinHayaran"
To: "Django developers"
Sent: Tuesday, February 17, 2009 6:40 PM
Subject: Is this true. tha
Hi,
I did a reply on the post. Might be some time before it's approved.
The gist is that yes it's that bad if you're using it naively. As long
as you know what's gonna be loaded from the DB you can avoid those
cases pretty easily.
You can also check
http://github.com/dcramer/django-idmapper/tree
On Tue, Feb 17, 2009 at 6:40 AM, NitinHayaran wrote:
>
> Hi All,
> Today i read this article and was wondering whether django orm is
> really that bad.
>
> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
>
> I think this is the right place to ask?
This seems to
Hi All,
Today i read this article and was wondering whether django orm is
really that bad.
http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
I think this is the right place to ask?
--~--~-~--~~~---~--~~
You received this message
No comments on the more efficient perms/contenttypes implementation?
I'd really like to know if that is an option because if it's not I
should better make app-engine-patch 1.0 compatible with the less
efficient implementation. Hmm, or I could emulate those db tables in
the backend, but that wouldn
32 matches
Mail list logo
