Re: Problem with too many indexes (SVN-7438) and (slightly) better index on auth_user?
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 (reducing locks, etc) and also would help on a successful login attempt if you're only pulling out those two columns. Django (I think?) pulls out all the columns so it probably needs to read the table anyway on a successful attempt. Minor performance enhancement for most sites but easy to implement. The pk index problem is definitely a much bigger deal for those who aren't going around pruning indexes. On Apr 29, 9:24 pm, David Cramer <[EMAIL PROTECTED]> wrote: > +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 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=50) > > > class Season(models.Model): > > name= models.CharField(max_length=50) > > > class LeagueSeason(models.Model): > > league = models.ForeignKey(League) > > season = models.ForeignKey(Season) > > > In LeagueSeason it will create the PK index on league + season (which > > is correct), but then it will create an index on league and another on > > season. The one on season should be created, but the one on league > > should NOT be created since the PK index can be used. One to ones are > > a simpler example and the 2nd index should never be created. > > > Better index on auth_user? > > auth_user.username might as well have username and password in the > > index since you usually query both and if you only query one, that's > > ok, the index will still work. Since the typical use case for that is > > login via username/pw, you never have to hit the table can just use > > the index to pull the password. Saves an extra read to the database. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 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 basis, > without warning and with backwards incompatable changes. > > Now given the fact that these changes are expected and anticipated by > most, it is expected people keep an eye on the list. If you don't then you > cannot go round blaming the developers for something that they did. Your > excuse that you haven't got the time is valid, but yet not an excuse at all. > If you're using a development source for anything, then you must also keep > in touch with the information pertaining to that source, in this case > django-dev. If you cannot do that, then you shouldn't be using the > development sources. > > Now I know this is an issue that not just you experienced David, and I > myself was quite suprised to see that (despite it being mentioned on both > mailing lists, for which I saw) it is yet to be mentioned on the blog > (which, again, seems to have become forgotten, and is collecting dust). > Perhaps a recommendation from yourself then David could be that the Django > developers could make more active use of the Blog for this kind of thing? > I'm all for that because it was an Announcement of a major change, and that, > if not listed in a specific announcements mailing list, should be placed > somewhere of prominence for general users, eg the blog. > > There is an issue David, I agree. I just don't think your solution is > quite right. If you haven't time to pass over a few emails, then how do you > find the time to check a page every day? or even every half day? Also you > should check these things BEFORE you do a svn update, rather than after. > > Regards, > > Mike Scott > > > On Wed, Apr 30, 2008 at 2:25 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > 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 <[EMAIL PROTECTED]> wrote: > > > 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 > > > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/code/ > > > > > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 basis, without warning and with backwards incompatable changes. Now given the fact that these changes are expected and anticipated by most, it is expected people keep an eye on the list. If you don't then you cannot go round blaming the developers for something that they did. Your excuse that you haven't got the time is valid, but yet not an excuse at all. If you're using a development source for anything, then you must also keep in touch with the information pertaining to that source, in this case django-dev. If you cannot do that, then you shouldn't be using the development sources. Now I know this is an issue that not just you experienced David, and I myself was quite suprised to see that (despite it being mentioned on both mailing lists, for which I saw) it is yet to be mentioned on the blog (which, again, seems to have become forgotten, and is collecting dust). Perhaps a recommendation from yourself then David could be that the Django developers could make more active use of the Blog for this kind of thing? I'm all for that because it was an Announcement of a major change, and that, if not listed in a specific announcements mailing list, should be placed somewhere of prominence for general users, eg the blog. There is an issue David, I agree. I just don't think your solution is quite right. If you haven't time to pass over a few emails, then how do you find the time to check a page every day? or even every half day? Also you should check these things BEFORE you do a svn update, rather than after. Regards, Mike Scott On Wed, Apr 30, 2008 at 2:25 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> wrote: > > 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 > > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/code/ > > > --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 <[EMAIL PROTECTED]> wrote: > 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 > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/code/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Problem with too many indexes (SVN-7438) and (slightly) better index on auth_user?
+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 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=50) > > class Season(models.Model): > name= models.CharField(max_length=50) > > class LeagueSeason(models.Model): > league = models.ForeignKey(League) > season = models.ForeignKey(Season) > > In LeagueSeason it will create the PK index on league + season (which > is correct), but then it will create an index on league and another on > season. The one on season should be created, but the one on league > should NOT be created since the PK index can be used. One to ones are > a simpler example and the 2nd index should never be created. > > Better index on auth_user? > auth_user.username might as well have username and password in the > index since you usually query both and if you only query one, that's > ok, the index will still work. Since the typical use case for that is > login via username/pw, you never have to hit the table can just use > the index to pull the password. Saves an extra read to the database. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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.in/code/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: EmptyQuerySet
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 performance-wise to do an icontains like
I'm doing :)
-Eric Florenzano
On Apr 29, 5:00 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> 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 "none() returns an EmptyQuerySet
> that behaves like any other QuerySet object", so it would be nice if
> the above worked).
>
> 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 qs-rf, and in case you disagree about fixing this -- patch
> attached.
>
> Luke
>
> --
> "Where a person wishes to attract, they should always be ignorant."
> (Jane Austen)
>
> Luke Plant ||http://lukeplant.me.uk/
>
> EmptyQuerySetMerging.diff
> 2KDownload
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: EmptyQuerySet
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 qs-rf, and in case you disagree about fixing this -- patch > attached. Discussion of a similar issue is in ticket #7113: http://code.djangoproject.com/ticket/7113 I'd be inclined to agree with Malcolm that this should be fixed on QuerySet itself, rather than requiring every subclass or QuerySet-like class to special-case the logic. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
EmptyQuerySet
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 "none() returns an EmptyQuerySet
that behaves like any other QuerySet object", so it would be nice if
the above worked).
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 qs-rf, and in case you disagree about fixing this -- patch
attached.
Luke
--
"Where a person wishes to attract, they should always be ignorant."
(Jane Austen)
Luke Plant || http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Index: django/db/models/query.py
===
--- django/db/models/query.py (revision 7509)
+++ django/db/models/query.py (working copy)
@@ -132,15 +132,25 @@
def __and__(self, other):
self._merge_sanity_check(other)
-combined = self._clone()
-combined.query.combine(other.query, sql.AND)
-return combined
+if self.__class__ is EmptyQuerySet:
+return self
+elif other.__class__ is EmptyQuerySet:
+return other
+else:
+combined = self._clone()
+combined.query.combine(other.query, sql.AND)
+return combined
def __or__(self, other):
self._merge_sanity_check(other)
-combined = self._clone()
-combined.query.combine(other.query, sql.OR)
-return combined
+if self.__class__ is EmptyQuerySet:
+return other
+elif other.__class__ is EmptyQuerySet:
+return self
+else:
+combined = self._clone()
+combined.query.combine(other.query, sql.OR)
+return combined
# METHODS THAT DO DATABASE QUERIES #
@@ -495,6 +505,9 @@
"""
Checks that we are merging two comparable queryset classes.
"""
+if self.__class__ is EmptyQuerySet or other.__class__ is EmptyQuerySet:
+return
+
if self.__class__ is not other.__class__:
raise TypeError("Cannot merge querysets of different types ('%s' and '%s'."
% (self.__class__.__name__, other.__class__.__name__))
Index: tests/modeltests/lookup/models.py
===
--- tests/modeltests/lookup/models.py (revision 7509)
+++ tests/modeltests/lookup/models.py (working copy)
@@ -270,6 +270,14 @@
0
>>> [article for article in Article.objects.none().iterator()]
[]
+>>> Article.objects.none() | Article.objects.filter(headline='Article 1')
+[]
+>>> Article.objects.none() & Article.objects.filter(headline='Article 1')
+[]
+>>> Article.objects.filter(headline='Article 1') | Article.objects.none()
+[]
+>>> Article.objects.filter(headline='Article 1') & Article.objects.none()
+[]
# using __in with an empty list should return an empty query set
>>> Article.objects.filter(id__in=[])
RE: QSRF Related
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@googlegroups.com Subject: Re: QSRF Related 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 update from svn. You may as well consider each revision a release. We're working from trunk code in production. This means that we don't update very often, and on each such update we look for backwards incompatible changes, test projects, etc. The thing is, svn doesn't force you to upgrade at inconvenient time. You can choose whatever revision suits you and make an internal release. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 :) When you decided to use the trunk, each revision is a new version. It's your responsibility to follow at least those feeds: http://code.djangoproject.com/log/django/trunk/docs?limit=10=stop_on_copy=rss http://pipes.yahoo.com/pipes/pipe.run?_id=eBkuqM7C3BG9t0vuJhOy0Q&_render=rss What if you need the doc for the revision just before the qs-fr merge? With the recent sphinx generator addition it's really easy to generate your own local copy of the documentation with your revision. David --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 closest thing to a changelog is svn log. You just need to correct your understanding of tracking trunk - you can not expect to be able to update blindly and have things not break. Until 1.0 lands, backwards incompatible changes *will* happen, so you must expect that "svn up" may break your code, especially if you're using undocumented internals. -- Collin Grady A professor is one who talks in someone else's sleep. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 update from svn. You may as well consider each revision a release. We're working from trunk code in production. This means that we don't update very often, and on each such update we look for backwards incompatible changes, test projects, etc. The thing is, svn doesn't force you to upgrade at inconvenient time. You can choose whatever revision suits you and make an internal release. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
RE: QSRF Related
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 Message- From: James Bennett <[EMAIL PROTECTED]> Sent: Tuesday, April 29, 2008 1:57 PM To: django-developers@googlegroups.com Subject: Re: QSRF Related 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't > expecting, especially since the closest thing to a changelog is svn log. I still don't see how more releases would help you -- if you're relying on an API that wasn't public/documented before and wasn't public/documented after the change, what exactly does a release do for you that the list of backwards-incompatible changes doesn't already do? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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't > expecting, especially since the closest thing to a changelog is svn log. I still don't see how more releases would help you -- if you're relying on an API that wasn't public/documented before and wasn't public/documented after the change, what exactly does a release do for you that the list of backwards-incompatible changes doesn't already do? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
RE: QSRF Related
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. -Original Message- From: James Bennett <[EMAIL PROTECTED]> Sent: Tuesday, April 29, 2008 1:46 PM To: django-developers@googlegroups.com Subject: Re: QSRF Related 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 releases could > help :) How would releasing more often make it easier to find out what's changed in an undocumented API? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 releases could > help :) How would releasing more often make it easier to find out what's changed in an undocumented API? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
RE: QSRF Related
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]> Sent: Tuesday, April 29, 2008 12:25 PM To: django-developers@googlegroups.com Subject: Re: QSRF Related 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 > > pointed it out to me) > > Er, no, the public, documented API didn't really change much at all. > And people who were doing work deep under the hood presumably were > smart enough to be paying attention and so don't need a big screaming > warning that queryset-refactor was taking place. Also, the few changes that are noteworthy are linked to from the usual place,[1] where everyone who's updating SVN is regularly informed to look anyway. Any new features use the usual "New in Django development version" as well. -Gul [1] http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 > > pointed it out to me) > > Er, no, the public, documented API didn't really change much at all. > And people who were doing work deep under the hood presumably were > smart enough to be paying attention and so don't need a big screaming > warning that queryset-refactor was taking place. Also, the few changes that are noteworthy are linked to from the usual place,[1] where everyone who's updating SVN is regularly informed to look anyway. Any new features use the usual "New in Django development version" as well. -Gul [1] http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Problem with too many indexes (SVN-7438) and (slightly) better index on auth_user?
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=50) class Season(models.Model): name= models.CharField(max_length=50) class LeagueSeason(models.Model): league = models.ForeignKey(League) season = models.ForeignKey(Season) In LeagueSeason it will create the PK index on league + season (which is correct), but then it will create an index on league and another on season. The one on season should be created, but the one on league should NOT be created since the PK index can be used. One to ones are a simpler example and the 2nd index should never be created. Better index on auth_user? auth_user.username might as well have username and password in the index since you usually query both and if you only query one, that's ok, the index will still work. Since the typical use case for that is login via username/pw, you never have to hit the table can just use the index to pull the password. Saves an extra read to the database. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
django_session table
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 pointer). If it's a fixed length row, the DB can find the row much quicker since it can just calculate the location. It's obviously not a critical fix, since if you really wanted performance you would run it on memcached instead, but still would be nice. P.S. This is my first post in the group. Love Django! --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 it out to me) > Evidently you missed it, but an announcement was posted both to the users and dev list with links to the updated docs and backward compatibilities etc. You can read that announcement here[1]. It (and the provided links) should answer all (most?) of your questions. [1]: http://groups.google.com/group/django-developers/browse_thread/thread/f4cd02d8d9389669 -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
> 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/django-developers/browse_thread/thread/fb195cbcda2e4b44/f85fb54382a7847a?#f85fb54382a7847a). You might want to read that thread. Michael Trier http://blog.michaeltrier.com/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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. This is why a good bug report has sections titled "what I expected to happen" and "what actually happened"; none of that can be inferred from the one-liner you posted. > 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 it out to me) Er, no, the public, documented API didn't really change much at all. And people who were doing work deep under the hood presumably were smart enough to be paying attention and so don't need a big screaming warning that queryset-refactor was taking place. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
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 "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
WILL BREAK" (I didn't even know QSRF was released until someone
pointed it out to me)
On Apr 29, 10:51 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> 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 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 :)
>
> Documentation update worked like any other documentation update from
> any other commit of any other feature(s).
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: QSRF Related
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 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 :)
Documentation update worked like any other documentation update from
any other commit of any other feature(s).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: QSRF Related
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, all the new docs were merged in also, just mixed in with the normal db-api and model-api pages, among others. -- Collin Grady Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll invite himself over for dinner. -- Calvin Keegan --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: API question for model saving
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 but it added _is_stored to models. This seems a lot cleaner and is more standard through DB implementations. On Apr 28, 5:02 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote: > > > For this particular case it saves a whole line. One concern I have is > > > that if there's more complex logic in your overridden save method, some > > > of it is going to be useful in both cases and now you have to create > > > extra sub-functions for the common bits and remember to call them both > > > times. It leads to duplication. If you look around at sample code on > > > django-users and other places, you can see people doing a number of > > > pieces of auxilliary processing as a result of save happening on the > > > instance, so this isn't a trivial issue. > > > No, it does not duplicate code, as you still could use save() for common > > code. > > Common stuff *must* to be called from both create() and update() in your > case because you're proposing that people should be allowed to call them > directly. > > That means save() is only ever going to be a placeholder for backwards > compatibility. Not worth it. > > > > > > > >> BTW, create()/update() sounds more explicit to me than save(). > > > > Which immediately leads to one of the problems with it. Suppose I'm > > > writing a function that accepts objects, does something to them and then > > > wants to save them. Do I call create() or update()? There's no way to > > > tell. Currently, I call save() with no ambiguity problem. > > > > Also, this presents an unnecessary backwards-incompatibility. Every > > > single piece of code now has to change to use one or other of these > > > methods. Every save() call. Currently and with the parameter approach, > > > *zero* existing code has to change initially. If you want to support the > > > must insert vs. must update difference, you can add a parameter (or two, > > > depending on which approach we take) and it's still backwards > > > compatible. > > > Sorry, but this sounds like you did not read my email at all (to which > > David Larlet sent a reply). I proposed still having save(), but > > implementing it like this: > > I did read your mail. Then, whilst writing my reply, I forgot that you > had proposed this plan because I was noting the problem with the common > code. save() becomes a dead method here unless people are forced to call > it. If an individual wants to split their save() handling into a create > and an update path in separate functions, that's fine. They can do that. > But Django's core doesn't need to do that; there just isn't the amount > of code to require it. > > I didn't mean to dismiss your code fragment, David. I apologise. I was > trying to collapse multiple responses into one. > > [...] > > > You don't have to stick to this names. I just used them, as I think they > > are pretty self-explainig. > > The point is that any names have the potential for a clash. We're very > miserly about taking names form the common namespace for that reason: > you have to pick something easily understandable and not likely to > collide. Not introducing any new names is safest of all. > > Regards, > Malcolm > > -- > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch on #6776
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 patch. > Any model that is being imported, whether it is in the installed > apps or not, is being put into the admin. This is a real hassle for > multiple sites that might share for example a user profile. Ah, that is a good catch. I will go ahead and get that fixed up. Thank you for your feedback. Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch on #6776
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 duplicate because you can't reproduce it in the shell or on the dev server, but I had a fairly reliable setup that was causing this error and it isn't right now). Thanks again Brian for the great work. On Tue, Apr 29, 2008 at 10:07 AM, Michael <[EMAIL PROTECTED]> 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 patch. Any > model that is being imported, whether it is in the installed apps or not, is > being put into the admin. This is a real hassle for multiple sites that > might share for example a user profile. > > I don't really have a solution. Maybe there is a different standard to > import admin? > > Michael > > > On Mon, Apr 28, 2008 at 6:09 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > > > > I have attached a patch to #6776 [1] that solves the AlreadyRegistered > > [2] problem according to what seemed to be the consensus. Which > > basically is to throw the AlreadyRegistered exception on registration > > of a different ModelAdmin that may have been previously registered > > with a model. I am looking to gather some input. It seems that I have > > needed to implement this similar to the way the AppCache works, which > > deals with locking the cache when loading new apps. I am not 100% sure > > whether I need this or not. > > > > Thoughts? > > > > [1]: > > http://code.djangoproject.com/attachment/ticket/6776/6776_modeladmin_fix.2.diff > > [2]: > > http://groups.google.com/group/django-developers/browse_frm/thread/1a40c64e9c952c48/7e3d1967d71e4edc?tvc=1=ModelAdmin#7e3d1967d71e4edc > > > > Brian Rosner > > http://oebfare.com > > > > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: sql_queries does not include all the sql statements
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 questions. http://groups.google.com/group/django-users/browse_thread/thread/1d3cd3bcd0bb3e6b Best regards, Simon Willison --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django port on OpenVMS - Oracle/Rdb backend
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 systems, so in different processes, or it is mandatory to run in a one-process/multi-threads environment. - I have noticed that some database access are done without call to the database operations start_transaction_sql() , so use an implicit database start transaction. Is it a bug? - Also transactions which do no change are not commited, it seem that it's feature but IMHO it's a bug. Some database systems execute select statement in a transaction context and may lock record to maintain consistency (depend on the isolation level setting) until you commit or rollback the transaction. I would be nice to have, at the end of the http request an commit to be sure to close the transaction and release any outstanding locks. - date field parameter use timestamp format instead of date format for example use '2008-01-01 00:00:00' instead of '2008-01-01' and integer parameter sometimes use string instead of int. Is it a feature or a bug? Tanks for any informations, Jean-François --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Aggregate Support to the ORM
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 income, what should
> the values of the name field be? None might make sense at first, as Honza
> suggests, but what happens to methods that depend on name? The whole point
> of returning models is to have access to the methods and other class
> metadata, but if data is missing or not meaningful, then those methods might
> not be useful.
>
In this case: should we actually return the actual objects? If a
values modifier is involved the expected behavior is to receive a list
of dicts. IMO, we should not allow aggregates to override this
behavior. Also, having some value for the fields wouldn't make sense
since we cannot ensure there is a unique value for a given field for
that group (unless it is specified in values, in which case it would
automatically appear).
I like the idea of having a QuerySet for retrieving the grouped
objects. This can be done simply by having something like: {'objects':
}
>
> > I dont see the problem in averaging an integerField (probably in
> > averaging a CharField, but IMHO this kind of invalid values should
> > make the whole query fail).
> >
> >
>
>
>
> The problem with averaging an IntegerField is that the result is unlikely to
> be an integer, yet parts of the model might assume that it is. At the very
> least AggregateModels in this situation are unable to be validated, saved or
> deleted, and it's possible that other methods don't work, so either they
> shouldn't be models at all, or we need to disable lots of things and issue
> big, big warnings.
>
or they can be a list of Models only when no 'values' is specified.
> >
> > I aggre. An advantage (which I think might also be a double edge
> > sword) of the string function names is the possibility to fallback to
> > a standard convertion to SQL when no function is defined.
>
> I'm not sure how wise this is. Considering the variation of available
> functions, and their different behaviors, just passing the function name
> straight into SQL could easily encourage non-portable queries. I know some
> users will want DB specific functions, but like extras, it should probably
> be clearly advanced functionality.
>
I am not sure either. I see the problems it might bring.
> Ideally expressions.py should be import * friendly
>
> >
> > > In addition, some cases have special requirements and dealing with them
> in a
> > > class is easy.
> > >
> >
> > I can't think of a requirement that can't be dealt with in a method
> > also... got an example?
> >
>
>
> Count() is an easy example. First, it takes an extra kwarg, 'distinct', and
> changes the output of as_sql() if set. Then it also has to do a special case
> in relabel_aliases() and whatever method passes column names to
> query.setup_joins() for COUNT(*)
>
This could all be handled in a count method. Still I see that using
classes poses and advantage.
>
> Cheers,
> Justin
>
>
>
> >
>
Regards,
--
Nicolas Lara
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
sql_queries does not include all the sql statements
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? --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
