On Saturday 18 March 2006 00:50, Russell Keith-Magee wrote:
> Again, look back at the archives.
>
> http://groups.google.com/group/django-developers/browse_thread/thread
>/4a6c67a2df095b43/bb00c30c7ba63bdf
>
> For the record, I would be +1 on Article.objects returning a
> non-cached query set, an
On 3/18/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Why don't we use something simple, like tuples:
>
> pubdate=('year', 2005)
> name='John' (it is possible now)
> fname=('contains','n')
Interesting, but I'm not sure I see the advantage. I don't think this
notation is inherently more obvio
On Fri, 2006-03-17 at 19:30 -0600, Eugene Lazutkin wrote:
> What was the motivation behind using complex kwargs like (taken from
> http://code.djangoproject.com/wiki/RemovingTheMagic):
>
> pubdate__year=2005
>
> fname__contains='n'
> name__exact='John' (can be abbreviated to name='John')
> and
Eugene Lazutkin wrote:
> What was the motivation behind using complex kwargs like (taken from
> http://code.djangoproject.com/wiki/RemovingTheMagic):
>
> pubdate__year=2005
>
> fname__contains='n'
> name__exact='John' (can be abbreviated to name='John')
> and so an?
>
> Why don't we use someth
True, Jan. I have updated the patch so it won't break the admin app now.
--~--~-~--~~~---~--~~
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
What was the motivation behind using complex kwargs like (taken from
http://code.djangoproject.com/wiki/RemovingTheMagic):
pubdate__year=2005
fname__contains='n'
name__exact='John' (can be abbreviated to name='John')
and so an?
Why don't we use something simple, like tuples:
pubdate=('year',
On 3/17/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> >>> len(connection.queries)
> 3
This is by design. Every call to all() produces a new query set. This
behaviour has been discussed a few times, usually in the context of
renaming all() 'cached()', whether caching should be the default or an
opti
On Monday 13 March 2006 21:24, Adrian Holovaty wrote:
> On 3/13/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> > If I create a model in my app with foreign key to the User model,
> > the SQL for creating the table doesn't add a 'REFERENCES' clause:
> > [...]
> > It works fine for intra-app relations
Op do, 16-03-2006 te 17:27 -0800, schreef SmileyChris:
> This has been discussed earlier on the list, but a simple solution was
> sitting there waiting to be implemented so I just put a patch
> together.
> Does anyone see any problems with it?
Yes, like I said on the ticket, your patch (just lik
Max Battcher wrote:
> So, I'm not sure if such an improvement is really necessary, again as
> the biggest case I see _for_ it being template performance, and I'm
> wondering if there might be a better way to optimize that single edge
> instead (ie, is it worth it to have some caching added to
> d
10 matches
Mail list logo
