Travis Parker wrote:
> I was just recently optimizing database usage in a django app and
> found myself managing these things myself (sorted(qs) instead of
> qs.order_by(), filter(filterer, qs) instead of qs.filter()) because I
> didn't want the database to get hit again when modifying already-use
It has been brought to my attention that the specific ordering of
order_by is potentially different for different backends; it seems
that it must be sent to the database for consistency - in other words:
qs = Model.objects.all()
# ...something that evaluates qs
qs.objects.order_by('
On Tue, 2008-04-15 at 19:33 -0700, Travis Parker wrote:
> > Because every time you modify a QuerySet you are changing the results
> > that will be returned. Calling filter() will restrict the results.
> > Calling order_by() will change the order the results are returned in.
> > And so on. Thus, t
> Because every time you modify a QuerySet you are changing the results
> that will be returned. Calling filter() will restrict the results.
> Calling order_by() will change the order the results are returned in.
> And so on. Thus, the cache of the queyrset that was cloned is invalid
> for the new
On Tue, 2008-04-15 at 18:50 -0700, Travis Parker wrote:
> Is there a reason that QuerySet methods like order_by() or filter()
> don't simply pass on an appropriately modified version of their own
> cache to the new QuerySet?
Because every time you modify a QuerySet you are changing the results
t
Is there a reason that QuerySet methods like order_by() or filter()
don't simply pass on an appropriately modified version of their own
cache to the new QuerySet?
I was just recently optimizing database usage in a django app and
found myself managing these things myself (sorted(qs) instead of
qs.
http://code.djangoproject.com/ticket/7028
This little patch improves a lot the user feedback experience during
raw-id-fields selection.
When a big table hasn't a clear id (for example just a numeric id) and
an user chooses an item from the popup window, the item description
appears only after s
Honza Král wrote on 04/16/08 00:13:
> Hi,
> check out ticket #6845 ( http://code.djangoproject.com/ticket/6845 ).
> It enables you to define validators on both DB Fields and FormFields
> and should make your work much easier.
>
Hi Honza
Found your ticket just after posting this :)
Will keep an
Hi,
check out ticket #6845 ( http://code.djangoproject.com/ticket/6845 ).
It enables you to define validators on both DB Fields and FormFields
and should make your work much easier.
On Sun, Apr 13, 2008 at 6:09 PM, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> I've made a small change t
When using the google interface to make a new post I have seen
instructions as part of the 'new message' form for other groups. The
groups I am thinking of are all 'google' help/developer/etc groups so
it might not be something a general group can configure. I think
having instructions right in yo
On Mon, Apr 14, 2008 at 5:56 PM, Jay Parlar <[EMAIL PROTECTED]> wrote:
>
> On Sun, Apr 13, 2008 at 6:13 PM, Honza Král <[EMAIL PROTECTED]> wrote:
> > > I was going to say "Put the cache into self.foo", but now I'm just
> > > realizing that there is just one FormWizard instantiated in urls.py
thanks for this info and guidance, Malcolm
Michael Moore
On Apr 15, 7:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-04-15 at 04:42 -0700, ecsmoore wrote:
> > Sorry if this is the wrong place to post this.. redirect me if you
> > can.
>
> This isn't really the right place (i
On Tue, 2008-04-15 at 04:42 -0700, ecsmoore wrote:
> Sorry if this is the wrong place to post this.. redirect me if you
> can.
This isn't really the right place (it's the mailing list for internal
django development).
The django-users mailing list is a better place for this sort of thing.
Even
Sorry if this is the wrong place to post this.. redirect me if you
can.
I have an application that is 90% finished. The developer had to leave
the project. Is anyone interested looking at completing this? This is
well documented and I believe will be straight forward. Most of what
is necessary to
J. Cliff Dyer wrote:
> On Thu, 2008-04-10 at 20:26 +0200, Gábor Farkas wrote:
>> the point is,that in my opinion, 99% of all developers want to have
>> their unicode-data normalized, before they process it. (maybe they
>> don't know yet that they want it, but they want it :-)
>>
>
> I'd say it's
On Mon, 2008-04-14 at 23:56 -0700, Simon Litchfield wrote:
> Anyone who mixes the ORM with raw data-modifying SQL concurrently may
> well be in for a surprise.
>
> Scenario. Load your model; run your data-modifying SQL; then
> explicitly try to reload your model to refresh it's data. Gotcha. The
Lazy-loading sorry, not 'caching'
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send
17 matches
Mail list logo
