I use django.core.context_processors.debug to see the sql_queries in
template.
The raw sql of query
Entry.objects.all()[0,1]
does not in the sql_queries,but if I change the query like this
Entry.objects.all()[0]
and then the sql is in the sql_queries. why?
On Tue, Apr 29, 2008 at 1:25 AM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
>
>
> On Mon, Apr 28, 2008 at 2:10 PM, Nicolas E. Lara G. <[EMAIL PROTECTED]>
> wrote:
> > I didn't understand your point here. When is the data incomplete?
>
> An example would be grouping people by age and averaging
Hello,
I have successfully port Django to OpenVMS and have start to build an
Oracle/Rdb (http://www.oracle.com/rdb) backend.
A few questions:
- can Django run in a cluster environnement (OpenVMS has a "shared
everything" cluster design) , meaning running simultaneous Django
server on different
On Apr 29, 9:32 am, leopay <[EMAIL PROTECTED]> wrote:
> oh,I make a mistake the first query is
>
> Entry.objects.all()[0:1]
>
> but still have the problem
This is to do with lazy evaluation of querysets. I've posted an
explanation on django-users - please reply there if you have any more
After a few more sips of coffee, I thought I should also mention that this
does fix all the problems that I had with strange hidden AlreadyRegistered
errors. Specifically with mod_python doing these multiple imports. This
patch fixes #6718 at least with my initial tests (it is a hard ticket to
On Apr 29, 2008, at 8:07 AM, Michael wrote:
> Thanks for the work, Brian;
>
> I assume the patch that goes to /dev/null should be going to contrib/
> admin/loading.py. Don't really get a chance to work with git all too
> often.
>
> One thing that I am noticing real quick, while applying this
I don't really like the idea of having extra options on save (mostly
because I have a lot of save calls that already. Maybe I don't quite
see the point. I proposed an internal flag a while back which would
determine if something was actually being created or updated. I don't
think it was accepted
David Cramer said the following:
> 3) Most importantly. Is there a shiny new page in the documentation
> that I don't see tagged somewhere that explains the new functionality?
> If so, can we tag it as "Updated" or whatever is appropriate :)
The doc pages were updated with qsrf, so when it
On Tue, Apr 29, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> 2) Is the issue still present if you do
> extra(select={'myforeignkeyname': 1}) ?
Is the issue still present where you didn't explain what you were asking about?
> 3) Most importantly. Is there a shiny new page in
2) I thought the very smple example explained it. Selecting on a
related field which already is present (so naming the select field
something that exists) would cause it to disappear, no errors, no
warnings.
3) This is a pretty major change to Django, and there's nothing on the
page that says
On Tue, Apr 29, 2008 at 12:55 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> 2) I thought the very smple example explained it. Selecting on a
> related field which already is present (so naming the select field
> something that exists) would cause it to disappear, no errors, no
> warnings.
> 1) order_by() resets the ordering, but select_related() does not.
> Would it not make more sense to keep APIs the same? So something like
> order_by(False) and a similar option for select_related?
David,
I asked about order_by not working generitively here
On Tue, Apr 29, 2008 at 1:55 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> 3) This is a pretty major change to Django, and there's nothing on the
> page that says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
> WILL BREAK" (I didn't even know QSRF was released until someone
> pointed
We might want to consider a performance boost for those that choose to
use the django_session table over memcached. If
django_session.session_data is made a char(40) instead of a
varchar(40) most DB engines will make that row a fixed length row
(longtext/blobs are stored outside the row with a
When creating a one to one table or a table with a compound key..
Django wants to create an index for the PK/alternate key and also
another index on the same column(s) because it's a FK. For example, if
I have:
class League(models.Model):
name=
On Tue, Apr 29, 2008 at 2:02 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> > 3) This is a pretty major change to Django, and there's nothing on the
> > page that says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
> > WILL BREAK" (I didn't even know QSRF was released until someone
>
Yes im aware of the backwards incompatibility page but that mostly covers the
public api. A lot of time for our uses we have to go beyond just using the
public api. This is another situation where having more releases could help :)
-Original Message-
From: Marty Alchin <[EMAIL
On Tue, Apr 29, 2008 at 3:38 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> Yes im aware of the backwards incompatibility page but that mostly covers
> the public api. A lot of time for our uses we have to go beyond just using
> the public api. This is another situation where having more
If I update from python 2.4 to 2.5 I can expect some trouble unless I know what
has changed. If I update trunk, which is what is considered the only real
version to use right now, I may encounter problems that I wasn't expecting,
especially since the closest thing to a changelog is svn log.
On Tue, Apr 29, 2008 at 3:54 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> If I update from python 2.4 to 2.5 I can expect some trouble unless I know
> what has changed. If I update trunk, which is what is considered the only
> real version to use right now, I may encounter problems that I
When an api is limited how would you propose to extend it? You do it the way OO
is built. When releases happen you can expect things to break. When they don't
how do you expect to know when you are safe to update? Would .96.1 implement
bakckwars incompatible changes? Probably noy
David Cramer wrote:
> When an api is limited how would you propose to extend it? You do it the way
> OO is built.
> When releases happen you can expect things to break. When they don't how do
> you expect to
> know when you are safe to update?
From this point of view it's never "safe" to
David Cramer said the following:
> If I update from python 2.4 to 2.5 I can expect some trouble unless I know
> what has changed. If I update trunk, which is what is considered the only
> real version to use right now, I may encounter problems that I wasn't
> expecting, especially since the
Le 29 avr. 08 à 22:38, David Cramer a écrit :
>
> Yes im aware of the backwards incompatibility page but that mostly
> covers the public api. A lot of time for our uses we have to go
> beyond just using the public api. This is another situation where
> having more releases could help :)
Not debating what trunk actually is but digging through revisions just so you
can have x fix or y feature is the problem. Either way all of this is way off
topic.
-Original Message-
From: Ivan Sagalaev <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 2:26 PM
To:
Hi Malcolm,
After the queryset-refactor merge, code like this breaks:
Foo.objects.none() | Foo.object.filter(bar=123)
(This kind of thing is useful sometimes when building up a QuerySet in
stages. That isn't one of the use cases given for .none() in the
docs, but the test suite does say
On Tue, Apr 29, 2008 at 5:00 PM, Luke Plant <[EMAIL PROTECTED]> wrote:
> I've created a patch, which special cases EmptyQuerySet in a couple of
> places, which seems to be the simplest way of doing it. I can commit
> it myself, but I wanted to pass it by you first since I'm unfamiliar
> with
Funny, I just ran into this problem today and got the desired results
by doing:
from django.db.models import Q
from operator import or_
q_list = [Q(title__icontains=k) for k in keywords.split(' ')]
search_results = MyModel.objects.filter(reduce(or_, q_list))
...not that it's a good idea
On 29-Apr-08, at 11:25 PM, David Cramer wrote:
> WILL BREAK" (I didn't even know QSRF was released until someone
> pointed it out to me)
must have been about a million messages congratulating malcolm on the
mailing list ...
--
regards
kg
http://lawgon.livejournal.com
+1 on pk index fix
as for auth_user, username being indexed would be good, but I believe
the hash is calculated completely outside of SQL, so there's no need
to index password.
On Apr 29, 12:15 pm, Ed Menendez <[EMAIL PROTECTED]> wrote:
> When creating a one to one table or a table with a
I've been extremely busy over the last few weeks, and have rarely had
the chance to check the mailing list. I specifically disable email
updates from these because of all the mail I get each day. So sorry
for not having time (but I'm really not sorry).
On Apr 29, 5:50 pm, Kenneth Gonsalves
David,
The point here is that you were using a development source for your code.
Understandably people have started using this source more and more due to
the enhancements and features provided, and its general stability. But it is
stated everywhere that the source is subject to change on a daily
When did I blame anyone? I didn't even update to QS-RF yet. I just thought
it would be useful to put a big fat label on the website saying "hey trunk
just got a massive face lift".
On Tue, Apr 29, 2008 at 7:37 PM, Mike Scott <[EMAIL PROTECTED]> wrote:
> David,
> The point here is that you were
But you would still need to pull the password from the table to do the
comparison in the "WHERE" clause. If you over-indexed and captured the
password as part of the index, the database only has to read the index
to figure if your row matches. This helps eliminate a read on a failed
login attempt
34 matches
Mail list logo
