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
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 us
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 b
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 <[EMAI
+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 compou
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
http://nrcfosshelpline
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 performa
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
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 "no
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: django-developers@googl
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 :)
W
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 closes
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 upd
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
-Original
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 wasn
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: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 release
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 PROTECTED
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
>
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= models.CharField(max_length=
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 poi
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
> 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
(http://groups.google.com/group/dj
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.
Thi
On Tue, Apr 29, 2008 at 12:49 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Is it my understanding that aggregate would not return an actual
> object (from the original examples above).
>
> Also, in regards to HAVING support. Unless you plan to implement logic
> into .filter() which says "oh
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 "HE
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 the
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 merged
Hi guys, quick question,
I've found out the combo 'FormField+widget' does not solve my
flexibility needs (actually, my semantic markup guy's needs), so the
same form rendered in different contexts uses different markup for its
widgets (tags and classes), so instead of using the field's widget, I
w
Is it my understanding that aggregate would not return an actual
object (from the original examples above).
Also, in regards to HAVING support. Unless you plan to implement logic
into .filter() which says "oh hey this is from an aggregate, using
having" then this is a MUST. There's no other way y
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
Now that the branch is merged in I have a few things I'll nitpick
on :)
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?
2) Is the issue still present i
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
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
dupl
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 patch. Any
model that is being imported, whether it is in the i
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
question
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
oh,I make a mistake the first query is
Entry.objects.all()[0:1]
but still have the problem
On Tue, Apr 29, 2008 at 3:10 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I use django.core.context_processors.debug to see the sql_queries in
> template.
> The raw sql of query
>
> Entry.objects.all
On Tue, Apr 29, 2008 at 3:10 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I use django.core.context_processors.debug to see the sql_queries in
> template.
...
Please don't cross post messages between django-users and
django-developers. You won't increase the number of readers - you can
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 incom
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?
--~--~-~--~~~
41 matches
Mail list logo