Re: MySQL test failure

[Malcolm Tredinnick]

On Sat, 2009-04-04 at 01:21 -0400, Daniel Tang wrote:
[...]
> Not sure if this is an end-all solution, but you can pass a
> client_flag kwarg that makes MySQLdb return the number of matched rows
> instead of affected rows. In MySQLdb.constants.CLIENT there is a
> FOUND_ROWS constant. Passing it to connect resolves this problem.
> Patch attached just to show what I did.

Hmm ... didn't know about that one. Interesting and might well be worth
it.

The usual argument against that kind of thing is that we try to proxy
the cursor returned from MySQLdb.connect() fairly transparently, so that
people can use django.db.connection.cursor() as a fairly normal PEP 249
cursor. Your idea changes that behaviour, as now the database returns
something different from what it "normally" would.

However, it's a fairly minor change and given the relative ugliness of
the alternatives (in fact, it introduces a very small race condition),
it's worth thinking about.

Thanks for pointing it out.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MySQL test failure

[Malcolm Tredinnick]

On Fri, 2009-04-03 at 21:56 -0500, Jacob Kaplan-Moss wrote:
[...]
> 
> File 
> "/var/buildbot/slave/parts/ubuntu-8.04-python2.4-mysql5.0/django-trunk_ubuntu-8.04-python2.4-mysql5.0/build/tests/regressiontests/model_inheritance_regress/models.py",
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> ArticleWithAuthor.objects.filter(pk=article.pk).update(headline="Oh, no!")
> Expected:
> 1
> Got:
> 0
> """
> 
> Can someone with more MySQL-fu take a look and help me figure out
> what's going on?

Known problem. Russ brought it up a while back in a discussion about
what update() shoudl return and we haven't resolved it yet.

The issue is that MySQL only returns the number of rows *changed* when
executing an update command and that particular result will affect one
row, but changes no data in it. So it returns 0, not 1.

It's ticket #10438.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Matthew Marshall]

I'm interested.  Either weekend would work for me.

MWM

On Apr 2, 12:45 pm, Jeremy Dunck  wrote:
> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
> 4/17.
>
> Any preference?  Who can make it or will consider making it?
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: A bunch of little fixes

[Malcolm Tredinnick]

On Fri, 2009-04-03 at 17:50 +0200, Raffaele Salmaso wrote:
> * add app_label name to related_name
> http://code.djangoproject.com/ticket/9638

[... etc, etc...]

What are you wanting to achieve here? Are some of these actual bug fixes
(as opposed to feature enhancements) that are not already in the 1.1
milestone and cannot wait until later?

I just did a random sampling of four tickets and #10504 is a feature
addition, it can wait until 1.2 (and maybe even then isn't actually
something to do, since render_to_response is a *shortcut*, not a
complete replacement). #10647 and #9992 are already in the 1.1 milestone
an #10528 has been fixed.

My point being, we already have a huge list of open tickets that are
being worked on and you must be aware that we're in the lead up to a 1.1
release. Posting a list of ticket numbers with no explanation of why
they're more important than the existing ones isn't helpful. Size
doesn't matter at this point. Sometimes the quick ones won't be fixed
first, because they're something that, by definition can be fixed in
idle moments when we're taking a break from something else, or towards
the end in a hurry. It's the problems that are big bugs requiring more
thought that have to be done first, since they are the ones that could
well take a lot longer to resolve than we can reliably estimate.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Preston Timmons]

Yes, either weekend works.

On Apr 3, 2:54 pm, Nizam Sayeed  wrote:
> Yeah. We're open for either weekend.
>
> On Apr 3, 1:22 pm, Brett Hoerner  wrote:
>
>
>
> > On Fri, Apr 3, 2009 at 12:38 PM, Nizam Sayeed  
> > wrote:
> > > Count me in and a friend of mine as well.
>
> > > On Apr 3, 12:33 pm, Preston Timmons  wrote:
> > >> I would be interested in coming as well.
>
> > I assume you guys are OK with either weekend, then?
>
> > Brett
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Preston Timmons]

I would be interested in coming as well.



On Apr 3, 9:50 am, Jeremy Dunck  wrote:
> Gary, Justin?
>
> On Fri, Apr 3, 2009 at 9:47 AM, Alex Robbins
>
>
>
>  wrote:
>
> > I live in the Dallas area and would be interested in coming, whenever
> > it happens.
>
> > On Apr 2, 12:45 pm, Jeremy Dunck  wrote:
> >> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
> >> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
> >> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
> >> 4/17.
>
> >> Any preference?  Who can make it or will consider making it?
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

A bunch of little fixes

[Raffaele Salmaso]

* add app_label name to related_name
http://code.djangoproject.com/ticket/9638

* creation of m2m not managed tables
http://code.djangoproject.com/ticket/10647

* avoid a js error in admin pages
http://code.djangoproject.com/ticket/10651

* check action permission
http://code.djangoproject.com/ticket/10609

* unicode name in unique_together
http://code.djangoproject.com/ticket/10645

* pass content_type in render_to_response
http://code.djangoproject.com/ticket/10504

* application names i18n in admin
http://code.djangoproject.com/ticket/10436

* excluded fields can be updated
http://code.djangoproject.com/ticket/10363

DOCUMENTATION
=

* file upload
http://code.djangoproject.com/ticket/10400

* clarify get_object_or_404 parameter
http://code.djangoproject.com/ticket/10709

* clarify admin reverse names
http://code.djangoproject.com/ticket/10528

* **extra_parameter in test client
http://code.djangoproject.com/ticket/9607

* get_profile/get_model
http://code.djangoproject.com/ticket/9992

-- 
()_() | That said, I didn't actually _test_ my patch.  | +
(o.o) | That's what users are for! | +---+
'm m' |   (Linus Torvalds) |  O  |
(___) |  raffaele at salmaso punto org |

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Jeremy Dunck]

Gary, Justin?

On Fri, Apr 3, 2009 at 9:47 AM, Alex Robbins
 wrote:
>
> I live in the Dallas area and would be interested in coming, whenever
> it happens.
>
> On Apr 2, 12:45 pm, Jeremy Dunck  wrote:
>> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
>> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
>> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
>> 4/17.
>>
>> Any preference?  Who can make it or will consider making it?
> >
>

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Alex Robbins]

I live in the Dallas area and would be interested in coming, whenever
it happens.

On Apr 2, 12:45 pm, Jeremy Dunck  wrote:
> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
> 4/17.
>
> Any preference?  Who can make it or will consider making it?
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Follow-up to "contrib.admin is slow with large, complex datasets"

[mrts]

Omission: the models and admin used in experiments have changed a bit
from the original post:

from django.db import models

class Base(models.Model):
name = models.CharField(max_length=10)
lots_of_text = models.TextField()

class Meta:
abstract = True

def __unicode__(self):
return self.name

class A(Base):
a_field = models.CharField(max_length=10)

class B(Base):
b_field = models.CharField(max_length=10)

class C(Base):
a = models.ForeignKey(A)
b = models.ForeignKey(B)
is_published = models.BooleanField()

---

from django.contrib import admin
from improve_admin.models import A, B, C

class CAdmin(admin.ModelAdmin):
list_display = ('name', 'a', 'b', 'is_published')
list_filter = ('a',)

def queryset(self, request):
qs = super(CAdmin, self).queryset(request)
return qs.only('name', 'is_published', 'a', 'b').select_related
().only('a__name')

admin.site.register(A)
admin.site.register(B)
admin.site.register(C, CAdmin)

On Apr 3, 3:03 pm, Mart Somermaa  wrote:
> and the resulting view is the worst possible: contents of *the large
> text field* are displayed in the changelist instead of __unicode__ --

Correction: __unicode__ still uses C.name, but as #10710 kicks in, the
contents of C.lots_of_text is actually referenced by C.name, so that
is displayed.
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Follow-up to "contrib.admin is slow with large, complex datasets"

[Mart Somermaa]

(Sorry for top-posting, Google Groups is misbehaving.)

Jacob argued on #django-dev that you can already achieve the only() 
behaviour by overriding ModelAdmin.queryset().

So I experimented with that. "The results were disappointing," as prof. 
Denzil Dexter from The Fast Show used to say :) .

Adding the following to CAdmin

def queryset(self, request):
qs = super(CAdmin, self).queryset(request)
return qs.only('name', 'is_published',
'a', 'b').select_related()

results in correct SQL, but due to bug #10710 [1] fields are shuffled 
and the resulting view is the worst possible: contents of *the large 
text field* are displayed in the changelist instead of __unicode__ -- 
which strikes me as a cruel April fools trick, except today is April 3:
http://img3.imageshack.us/img3/4295/afterlimitqueryset.png

Ideally,

def queryset(self, request):
qs = super(CAdmin, self).queryset(request)
return qs.only('name', 'is_published',
'a', 'b').select_related('a__name', 'b__name')

should work, but due to the same bug [1] that throws
FieldDoesNotExist: A has no field named 'b'.

I expect that [1] is more or less easy to fix and overriding queryset() 
in that manner will be eventually possible.

However, the conceptual question of whether we should do that by default 
remains open. That is, should we really SELECT(*) if we know in advance 
that only the fields in list_display will be displayed? Jacob argues 
that current behaviour is OK, admin is "fast enough" and queryset() can 
be used for advanced things -- which is a valid position, so I won't 
campaign further for the "optimal by default" cause. But the "10 users 
opening a default admin changelist page of 100 entries for objects that 
contain 100 KB of data (100 MB of memory use), only to display e.g. the 
couple of bytes in object title" case makes me still uncomfortable.

As an aside, note that queryset() is undocumented [2].

[1] http://code.djangoproject.com/ticket/10710
[2] http://code.djangoproject.com/ticket/10712

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: About ticket 5622

[Matias Surdi]

Alex Gaynor escribió:
> 
> 
> On Thu, Apr 2, 2009 at 1:55 PM, Matias Surdi 
>  > wrote:
> 
> 
> I think that the attached patch corrects the problem.
> 
> Is there still something missing in order to get it into trunk?
> 
> 
> Thanks!
> 
> 
> 
> 
> 
> It is, at a minimum missing tests.
> 
> Alex
> -- 
> "I disapprove of what you say, but I will defend to the death your right 
> to say it." --Voltaire
> "The people's good is the highest law."--Cicero
> 
> > 

I've attached a fix and the tests for it.



--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---