Hello,
Thanks for the link :)
I think the documentation would be better structured, then, if
https://docs.djangoproject.com/fr/4.0/ref/models/querysets/ would
reference your link.
I have not read all of Django documentation.
I do not know if it is expected that most developers would read everythi
This is explicitly called out in the documentation
at
https://docs.djangoproject.com/en/4.0/topics/db/optimization/#understand-queryset-evaluation
On Thursday, June 23, 2022 at 1:17:50 PM UTC-4 laurent...@gmail.com wrote:
> Hello,
>
> I made a simple test to check the number of queries done :
>
Op 18-03-15 om 07:38 schreef Jay Prasad:
Hi All,
I'm started Pyhthon and django ,give me some suggestions and which
sites was good .help me.thank you all
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsub
I believe sqlite supports "distinct" just not "distinct on". I have always
managed to find workarounds using "distinct" anywhere I formerly used
"distinct on".
On Mar 6, 2013 7:01 AM, "Toran Billups" wrote:
> I recently upgraded to django 1.4 and found that my "distinct" queries
> don't work anym
Also, depending on your scenario, the classes might be overkill. You
could just as easily pass in a callable. In that case your view would
look something like this...
def suggest(request, usrid=None, get_friends=__get_friends):
current_user = request.facebook.user
facebook_friends = get_fr
Here is one approach...
class FBFriends:
def get_friends(self, current_user):
return __get_friends(current_user) # heavy call
def suggest(request, usrid=None, friend_source=FBFriends()):
current_user = request.facebook.user
facebook_friends = friend_source.get_friends(current_
James,
I don't think model should know anything about request like is IP
address. This would violate MVC principle.
Bojan
On May 29, 1:25 am, JamesJOG wrote:
> I have a model with an IPAddressField (1) and some views that have to
> write to that field every time they save (2) ... Wouldn't it be
Thanks for the update. This is very useful information.
On May 10, 9:41 pm, Karen Tracey wrote:
> On Sun, May 10, 2009 at 8:45 PM, tekion wrote:
>
> > Yes. I saw this link. My impression on first read is that it imports
> > the database into Django's database. I am not looking for this. I am
>
On Sun, May 10, 2009 at 8:45 PM, tekion wrote:
>
> Yes. I saw this link. My impression on first read is that it imports
> the database into Django's database. I am not looking for this. I am
> looking to just be able to read in the data from the external database
> and leave the maintenance of th
Yes. I saw this link. My impression on first read is that it imports
the database into Django's database. I am not looking for this. I am
looking to just be able to read in the data from the external database
and leave the maintenance of the database to the external
application. Has anyone done
This might be useful;
http://docs.djangoproject.com/en/dev/howto/legacy-databases/
It describes how to create models for your existing databases. However, it
wont stop you being able to make writes with the django ORM.
Dougal
---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/
2009/5
>
> > Talking through my hat?No, I think not -- I think that syntax
> > (``queryset.groupby(field).max()``)
> actually looks like the best proposal for aggregates I've seen thus far...
>
Sounds pretty good to me. Besides the usual min, max and such, I also
like:
queryset.groupby(field).stats()
On 12/4/06 5:57 AM, John Lenton wrote:
> The "max", "min" and other such functions might be a little more
> problematic, unless groupby returned, rather than a generic iterator,
> a special "queryset group" and give _it_ the max/min/etc methods. This
> way it would be clear that max() returns a tu
On 12/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> One way to think about the problem is to consider how you would write
> the documentation for it. "Django implements an object based SQL
> wrapper... except for the aggregations stuff, which you will need to
> know SQL to use properly"
On 12/2/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> But isn't it also dangerous to code (or not code) for future cases that
> may or may never come? If a non-relational database backend isn't
> anywhere on the current horizon, why not code aggregates and groups to
> the current usage and break
On 12/1/06 11:40 AM, Rob Hudson wrote:
>> 4 - If you search the archives (user and developer), you will find several
>> discussions on aggregate functions. group_by() and having() (or
>> pre-magic-removal analogs thereof) have been rejected previously on the
>> grounds that the Django ORM is not i
Thanks for the reply, Russell. It's obviously a lot more complex and
detailed than simply adding a min() where count() is. :)
A couple thoughts...
> 4 - If you search the archives (user and developer), you will find several
> discussions on aggregate functions. group_by() and having() (or
> pr
I'd like to see this type of support in the main branch, not separated.
It seems that better support for floating point is just a deficiency in
Django today and the aggregation need crops up everywhere - not just in
scientific applications.
My needs for aggregation are simply for reporting: e.g.
Yeah it is all coming back to me. I was unwilling to answer all of
these questions and create the perfect solution (which may not exist)
and therefore we don't have aggregates in Django even though I
demonstrated that a straightforward implementation was possible way
back when. Thanks for backing
On 11/30/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
>
> I think for those who need aggregate data these would cover a lot of
> ground. I'd be willing to work on a patch if this is considered
> generally useful and we can work out what the API should look like.
>
>
1 - I'm agreed on the need for e
On Nov 29, 2:30 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> > I needed aggregates. (I also learned about data bubbles and redesigned
> > my tables to include them as necessary. This redesign eliminated almost
> > all of my needs for an aggregate function interface.)Whatsa data bubble?
> >
> I needed aggregates. (I also learned about data bubbles and redesigned
> my tables to include them as necessary. This redesign eliminated almost
> all of my needs for an aggregate function interface.)
Whatsa data bubble? Google and Wikipedia don't seem to know...
--~--~-~--~~-
I created such a patch last spring during the Django sprint at PyCon.
The basic interface was very straightforward but there was also a
slightly less straightforward interface option that allowed for
grouping and so forth. The patch was discarded, however, since some of
the core Django developers
23 matches
Mail list logo
