Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Joshua Partogi]

I agree. In programming world, a 'user' is actually someone that
develops something with that framework or programming language. This
is quite contrast compared to OS world. The term 'Linux user' would
imply someone that actually use Linux, while Linux developers would
imply someone that is developing Linux.

Regards,

On May 12, 7:12 am, Glenn Maynard  wrote:
> Better names for django-users and django-developer would have been
> django-developer and django-core, respectively.  Calling this list
> "developer" wasn't such a great idea--the users of Django *are*
> developers; they're developing with Django.  No amount of tweaking the
> list description is going to fix the unintuitive naming.

--~--~-~--~~~---~--~~
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: Reduce bug triage overhead: DjangoAwesomeBot

[Glenn Maynard]

On Wed, May 6, 2009 at 11:39 AM, Henrique Romano  wrote:
> On May 6, 2009, at 7:23 AM, Russell Keith-Magee wrote:
>> 2. Does the patch contain a test?
>> 3. Does the test fail if the rest of the patch isn't applied?

In principle, you can answer these together.  Apply the patch to just
the tests directory, and run tests.  Revert, apply the entire patch,
and run tests again.  In general, everything should pass in the latter
and at least one test should fail in the former.  (Of course, all
tests need to be passing before the patch for this to work, which
isn't always the case.  You could run tests with nothing applied and
ignore the tests that fail, but that's getting hairier, and then it's
running tests three times.)

>> You also need to consider the fact that Trac doesn't much automated
>> metadata to interpret which patches are valid at any given time. A
>> complex ticket may have multiple patches, only some of which will
>> apply at any given time; in addition, there may be competing
>> approaches being discussed, so multiple tickets may be valid.

I'd recommend that it not attempt to triage the entire ticket, but
each individual patch attachment.  Add the results of testing each
patch as a comment: "passed", "test missing", "test failed" with a
backtrace, etc.

Also, standardize on putting the revision number in the patch, eg.
foo-r1234.diff.  The bot can trivially parse this out if it's present,
and test against that revision (else trunk).  This also makes the test
results much more fixed and reproducable.

(Answering the question "does the patch still work today" is useful
too, but would probably need some external interface to request that a
patch be re-tested against trunk.)

-- 
Glenn Maynard

--~--~-~--~~~---~--~~
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: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Glenn Maynard]

On Mon, May 11, 2009 at 5:43 PM, James Bennett  wrote:
> There are no "intuitive" or "right" names, really ("django-core"
> wouldn't work because this list is for more people than just the
> "core" team, for example -- nothing short of
> "developers-who-work-on-and-contribute-to-Django's-codebase-and-not-just-people-who-use-Django-because-those-people-belong-on-the-other-list"
> would work). Can we accept that the bikeshed's been painted?

I don't know where you got "the core team" from--django-core:
development on Django itself, and more importantly, it would have been
completely unambiguous to users developing using Django.

But it's obviously not worth changing now.   That's why I said "would
have been".  The notion of inverting the meaning of -developer at this
point--in the name of reducing confusion--is rather amusing, though.

-- 
Glenn Maynard

--~--~-~--~~~---~--~~
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: Posting to the wrong list (was: Re: Need Django Developer urgent)

[James Bennett]

On Mon, May 11, 2009 at 5:12 PM, Glenn Maynard  wrote:
> Better names for django-users and django-developer would have been
> django-developer and django-core, respectively.  Calling this list
> "developer" wasn't such a great idea--the users of Django *are*
> developers; they're developing with Django.  No amount of tweaking the
> list description is going to fix the unintuitive naming.

There are no "intuitive" or "right" names, really ("django-core"
wouldn't work because this list is for more people than just the
"core" team, for example -- nothing short of
"developers-who-work-on-and-contribute-to-Django's-codebase-and-not-just-people-who-use-Django-because-those-people-belong-on-the-other-list"
would work). Can we accept that the bikeshed's been painted?


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

Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Glenn Maynard]

Better names for django-users and django-developer would have been
django-developer and django-core, respectively.  Calling this list
"developer" wasn't such a great idea--the users of Django *are*
developers; they're developing with Django.  No amount of tweaking the
list description is going to fix the unintuitive naming.

-- 
Glenn Maynard

--~--~-~--~~~---~--~~
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: Quoting in extra(select=...) expression

[Ian Kelly]

On Mon, May 11, 2009 at 12:33 PM, lemming110  wrote:
>
> I am trying to use the select keyword in extra.  But I cannot properly
> quote the the expression for postrgres.  I am using the
> django.contrib.comments.  I started with this snippet
> http://www.djangosnippets.org/snippets/1101/ which returns the number
> of comments for an object.  However, the code does not work.  The
> problem that the field django_comment.object_pk is text and my item pk
> is integer.
>
> In postgres, this works:
>
> select count(*)
> from django_comments
> where django_comments.content_type_id=12 and
> django_comments.object_pk='332';
>
> But using extra(select={'comment_count': sql,}) where
>
> sql = '''select count(*)
> from django_comments
> where django_comments.content_type_id=12 and django_comments.object_pk=
> %s'''
>
> gives me an error every way that I have tried to add quotes.  (This
> includes django.db.connection.ops.quote_name.)
>
> Any ideas on how to embedded quotes in postgres?

Please ask questions about how to use Django on the django-users
mailing list.  This list is for discussion about the development of
Django itself.

Thanks,
Ian

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Quoting in extra(select=...) expression

[lemming110]

I am trying to use the select keyword in extra.  But I cannot properly
quote the the expression for postrgres.  I am using the
django.contrib.comments.  I started with this snippet
http://www.djangosnippets.org/snippets/1101/ which returns the number
of comments for an object.  However, the code does not work.  The
problem that the field django_comment.object_pk is text and my item pk
is integer.

In postgres, this works:

select count(*)
from django_comments
where django_comments.content_type_id=12 and
django_comments.object_pk='332';

But using extra(select={'comment_count': sql,}) where

sql = '''select count(*)
from django_comments
where django_comments.content_type_id=12 and django_comments.object_pk=
%s'''

gives me an error every way that I have tried to add quotes.  (This
includes django.db.connection.ops.quote_name.)

Any ideas on how to embedded quotes in postgres?


--~--~-~--~~~---~--~~
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: ticket 10032, joins and isnull=True

[Gábor Farkas]

On Mon, May 11, 2009 at 6:22 PM, Malcolm Tredinnick
 wrote:
> The choice to be made in an API implementation of this kind is whether
> NULL checks on fields in related models implies a related instance
> exists or not. Django follows SQL there and doesn't insist that a
> related row exists: absence of a row leads to NULL values for all
> columns in the potential related object.

ok, now i understand...  thanks for the explanation.

gabor

--~--~-~--~~~---~--~~
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: r9766-related issues

[Marty Alchin]

On Mon, May 11, 2009 at 8:45 AM, Armin Ronacher
 wrote:
> All bugs are fixed now except for #10788.  Now the problem with
> closing that one is that this one requires a design descision.  I
> updated the ticket accordingly for jacob or anyone else to decide on
> it.  My personal opinion is that I consider it bad design for the
> application to depend on the final filename of an uploaded file on the
> filesystem.  This makes it nearly impossible to create "atomic"
> uploads for unique filenames.

I've been thinking this one over a bit, while everybody else was
cleaning up the rest of my mess (thanks, guys!), and I have to agree
with you, at least to a point. I've only been able to come up with two
general uses for having the filename available at that point, and both
of them have a better approach available.

If you're using the filename to store it somewhere else, typically for
denormalization, it'd be better to do that post-save, since then you
know the record actually got saved in the database. Otherwise, you
might be trying to access the content of the file, which would be
better using the direct file access, which can often save yourself a
round-trip to the storage backend (which can be a big win for paid
storage solutions, like S3).

I won't completely discount the possibility that there's a legitimate
use case for having the final filename available in the pre-save hook,
but I just don't see it. I'll admit that it's a change to current
behavior, but I'm not sure there's a good way to get it working
reliably. I think it's possible to do it if we register our own
pre-save hook directly when the FileField is attached to the model
class, but even then, we can't guarantee that it's the first handler
to get registered, much less should we be relying on the ordering of
signal handlers anyway.

Unless somebody sees something I don't, I'm not sure there's a good
way to get it working, nor do I see much to be gained from doing so.

-Gul

--~--~-~--~~~---~--~~
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: r9766-related issues

[Armin Ronacher]

Hi,

All bugs are fixed now except for #10788.  Now the problem with
closing that one is that this one requires a design descision.  I
updated the ticket accordingly for jacob or anyone else to decide on
it.  My personal opinion is that I consider it bad design for the
application to depend on the final filename of an uploaded file on the
filesystem.  This makes it nearly impossible to create "atomic"
uploads for unique filenames.

Regards,
Armin

Links:
  http://code.djangoproject.com/ticket/10788
--~--~-~--~~~---~--~~
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: ticket 10032, joins and isnull=True

[Gábor Farkas]

On Mon, May 11, 2009 at 11:37 AM, Michael Radziej  wrote:
>
> On Mon, May 11, Gábor Farkas wrote:
>
>> Group.objects.filter(person__stamp__isnull=True)
>>
>> i get an OUTER JOIN,
>>
>> but if i do this:
>>
>> Group.objects.filter(person__stamp='2008-12-12')
>>
>> i get an INNER JOIN.
>>
>> please note, that the field i'm filtering on (stamp)
>> plays absolutely no role in the relation between
>> Group and Person. it's just there.
>>
>> for this reason i think
>> it's a bug, if django chooses different join
>> algorithms just because i'm doing an isnull-check
>> on that field (compared to when i do an exact-check
>> on the field).
>
> Django has to use an outer join in general if you join on nullable field.
> But if you tell Django that the person has to exist (and that is filtering
> for person__stamp='2008-12-12'), then it's safe to use an inner join.
>
> Why do you care for the join type at all?

because it produces different result :)

i agree that django has to use an outer join if you join on a nullable field.

but that's not the case here. the nullable field i have here is a DateTimeField.

we are talking about this sql:

SELECT "x_group"."id", "x_group"."name"
FROM "x_group" LEFT OUTER JOIN "x_person"
ON ("x_group"."id" = "x_person"."group_id")
WHERE "x_person"."stamp" IS NULL

as you see, it's joining on a normal foreign-key,
and then does a "WHERE" on the mentioned nullable field.

compare it to the sql produced for the "person__stamp='2008-12-12'" case:

SELECT "x_group"."id", "x_group"."name"
FROM "x_group" INNER JOIN "x_person"
ON ("x_group"."id" = "x_person"."group_id")
WHERE "x_person"."stamp" = E\'2008-12-12 00:00:00\'

why is an OUTER JOIN used in the first case,
and an INNER JOIN in the second?

i'm not saying that django should never use an outer join.
i'm only saying that in this case, there is no reason to switch
to a different join-type, just because i'm doing an IS_NULL
test on a completely unrelated field.

or, i overlooked something here. it wouldn't be the first time :-)

gabor

--~--~-~--~~~---~--~~
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: ticket 10032, joins and isnull=True

[Michael Radziej]

On Mon, May 11, Gábor Farkas wrote:

> i'd like to discuss ticket 10032, because it was closed as WONTFIX,
> ...
> Group.objects.filter(person__stamp__isnull=True)
> 
> i get an OUTER JOIN,
> 
> but if i do this:
> 
> Group.objects.filter(person__stamp='2008-12-12')
> 
> i get an INNER JOIN.
> 
> please note, that the field i'm filtering on (stamp)
> plays absolutely no role in the relation between
> Group and Person. it's just there.
> 
> for this reason i think
> it's a bug, if django chooses different join
> algorithms just because i'm doing an isnull-check
> on that field (compared to when i do an exact-check
> on the field).

Django has to use an outer join in general if you join on nullable field.
But if you tell Django that the person has to exist (and that is filtering
for person__stamp='2008-12-12'), then it's safe to use an inner join.

Why do you care for the join type at all?


Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

ticket 10032, joins and isnull=True

[Gábor Farkas]

hi,

i'd like to discuss ticket 10032, because it was closed as WONTFIX,
and i think the issue i raised was somehow misundersood,
perhaps i explained it the wrong way.

the problem is that i'm filtering a queryset
by doing a join using a foreign-key in the "opposite way",
and django sometimes does an INNER JOIN,
and sometimes an OUTER JOIN.

Malcolm's explanation was that the in the mentioned
situation both approaches are acceptable.

that's fine with my, but my problem is that
django switches between those 2 joins simply because
i did an isnull-test on an unrelated field.
when i did an exact-test on the same field,
django stayed with INNER JOIN.

the models are these:

class Group(Model):
name = CharField(max_length=20)

class Person(Model):
name = CharField(max_length=20)
group = ForeignKey(Group)
stamp = DateTimeField(blank = True, null = True)


now if i do this:

Group.objects.filter(person__stamp__isnull=True)

i get an OUTER JOIN,

but if i do this:

Group.objects.filter(person__stamp='2008-12-12')

i get an INNER JOIN.

please note, that the field i'm filtering on (stamp)
plays absolutely no role in the relation between
Group and Person. it's just there.

for this reason i think
it's a bug, if django chooses different join
algorithms just because i'm doing an isnull-check
on that field (compared to when i do an exact-check
on the field).

thanks,
gabor

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---