[Django] #17661: Foreign key with related name is not working properly.

[Django]

#17661: Foreign key with related name is not working properly.
--+--
 Reporter:  davisito89@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:  related_name
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 I created a class Person and a class Email. The relationship is 1:n (a
 person can have many emails and an email belongs to only one person). My
 class Email contains an attribute named person =
 models.ForeignKey(u"Person", related_name = u"emails"). Then I get some
 errors trying to get the emails of a single person:

 1. I created a person.
 Person.objects.create(id = 1)
 2. I created two emails.
 Email.objects.create(email = u"bla1", person = Person.objects.get(pk = 1))
 Email.objects.create(email = u"bla2", person = Person.objects.get(pk = 1))
 3. Try to get the emails of a person:
 Person.objects.all()[0].emails.all()[0].email (prints "bla2", instead of
 "bla1")
 Person.objects.all()[0].emails.all()[1].email (prints "bla2")
 But,
 [x.name for x in Person.objects.all()[0].emails.all()] prints "bla1" and
 "bla2" (which is the expected result).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by julien):

 There is also Ghost, which already supports `LiveServerTestCase`:

 http://jeanphix.me/Ghost.py/#django

 https://github.com/jeanphix/Ghost.py/blob/master/ghost/ext/django/test.py

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by julien):

 That said, I see that splinter is actually partially based on Selenium. So
 that might not really count ;)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by julien):

 There hasn't been any code updates to the Windmill repository since April
 2011 `[1]` or any blog/twitter updates for that project since November
 2010. I've also tried to get some feedback on the #windmill channel on
 Freenode but no one's replied yet. I'll continue trying to get a hold of
 the Windmill guys.

 In the meantime, if anyone is interested, you may also try using Splinter
 `[2]` instead as it's a much active project right now.

 `[1]` https://github.com/windmill/windmill/commits/master

 `[2]` http://splinter.cobrateam.info/

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I did try GDB but all I could get out of it is what looked like memory
 addresses which meant nothing to me. I'll rebuild the server and take it
 from there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by SmileyChris):

 You could easily keep the "tiny bit of debugging" with this:

 `if self.parent_name.filters or isinstance(self.parent_name.var,
 Variable):`

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by SmileyChris):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Needs a test and a quick note in the changes docs that the `ExtendsNode`
 definition changed (even though it's not documented, it's still a nice
 thing to mention)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by SmileyChris):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+--
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by FunkyBob):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Fair's fair... it was bradleyayers who brought this bug to my attention...
 I just formulated the patch.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+
 Reporter:  FunkyBob |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  SVN
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 For unknown reasons, the {% extends %} tag tries to manually identify
 string literals as the argument, by testing if they start and end with the
 same char, and that char is ' or "

 This test fails with the following trivial case:

 {% extends "something"|afilter:"else" %}

 I can see little to no reason not to switch to using the same argument
 filtering as everyone else, except for the _tiny_ amount of extra debug
 information provided.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17659: django_admin_log searches are slow

[Django]

#17659: django_admin_log searches are slow
-+-
 Reporter:  anonymous|Owner:  keeff
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 Adding some indexes makes sense to me. However, it would be nice to
 confirm both indexes are actually needed.

 Is it possible to provide some data on how these indexes are used in the
 queries Django generates for realworld data? EXPLAIN ANALYZE from
 PostgreSQL would be perfect.

 Multicolumn index could be the best solution here, but unfortunately that
 isn't currently supported. If possible, data for multicolumn index too
 would be great.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17659: django_admin_log searches are slow

[Django]

#17659: django_admin_log searches are slow
-+-
 Reporter:  anonymous|Owner:  keeff
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by keeff):

 * owner:  nobody => keeff
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17659: django_admin_log searches are slow

[Django]

#17659: django_admin_log searches are slow
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admin |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Queries against django_admin_log are slow because the soft-reference
 columns are not indexed.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by lrekucki):

 I can only add that you should try debugging it with GDB. Here is a link
 to mod_wsgi docs:

 
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17004: transaction.commit_manually decorator masks exceptions

[Django]

#17004: transaction.commit_manually decorator masks exceptions
-+-
 Reporter:  msoulier@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by umbrae@…):

 For the record for anyone else who stumbles upon this ticket - it's a
 duplicate of the issue found here:
 https://code.djangoproject.com/ticket/6623

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 The segfault is on the "get_response" method call, which executes the
 entire request/response cycle, so the actual line of code that triggers
 the segfault could be anywhere, including in your own codebase. In any
 case, a segfault indicates a bug in C code (Apache, mod_wsgi, or Python
 itself), not in Django; it's theoretically possible that Django could
 trigger such a bug, and might be able to work around it, but that would
 require first knowing where and what the actual bug is.

 Closing needsinfo, as there is no evidence of a bug in Django here.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Nothing really changed on the server though. Some python code was replaced
 with a slightly different version of same python code, then reverted back
 to the original. I do agree it is something on the server though, but a
 segfault like that with minimal information from wsgi.py prevents me from
 getting any way of debugging it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:  fixed
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  help color django-   |  Patch needs improvement:  0
  admin manage.py|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * severity:  Release blocker => Normal
 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * easy:  1 => 0
 * needs_docs:  1 => 0
 * ui_ux:  1 => 0
 * type:  New feature => Cleanup/optimization


Comment:

 revert spam

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 I really wonder if this is a bug in Django. All that can be concluded from
 the description (especially the "works on another server" part) suggests
 that there is something wrong with the server. Another hint is that
 upgrading and then downgrading and still getting this issue suggest that
 the problem is somewhere else.

 Maybe this should be closed as needsinfo? I don't know much about wsgi, so
 I don't feel confident doing that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 You could do a check in model.base_save(): connection.validate_pk(val),
 which should just raise an exception if the backend doesn't work with the
 given value. So, if you try to save a model with id=0, you would get an
 exception on MySQL on 0-valued PK value, and otherwise things would work
 as expected. This change should be simple to implement and safe to use. I
 don't think backwards compatibility for MySQL 0-valued PKs is worth
 worrying about: the current behavior can be considered a bug.

 Another option is to just skip this issue by saying this is a bug in
 MySQL, not in Django. But as in this case it is pretty easy to prevent the
 confusing behavior, then why not?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)
 * stage:  Unreviewed => Accepted


Comment:

 The same problem appears when you pass argument `id=0` to `__init__` of
 your model (in my example it's `Text`), see code below.
 {{{
 >>> t = Text(id=0, text="lorem ipsum")
 >>> t.id
 0
 >>> t.save()
 >>> i.id
 0
 >>> Text.objects.all()
 []
 >>> Text.objects.all()[0].id
 1
 }}}

 The problem appears with `MySQL`. `sqlite3` works properly. I've not
 checked other backends.

 I think that the problem is in `django.db.models.fields.AutoField` which
 is integer (see
 https://docs.djangoproject.com/en/1.3/ref/models/fields/#autofield)
 especially it can be zero. It should works like `PositiveIntegerField` or
 something like that. Supporting `AutoField` validation can be a solution,
 but it's backward incompatible. What's more, the validation is not
 necessary for backends other than MySQL because zero is valid value for
 `id` in most databases. We can check if `id` is not zero if the backend is
 MySQL otherwise don't validate `id`, but it makes the issue more comlex
 and it's still backward incompatible.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  aaugustin
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  help color django-   |  Needs documentation:  1
  admin manage.py|  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by anonymous):

 * severity:  Normal => Release blocker
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1
 * needs_docs:  0 => 1
 * ui_ux:  0 => 1
 * type:  Cleanup/optimization => New feature


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17462 - in django/trunk: django/core/management docs/ref docs/releases tests/regressiontests/admin_scripts

[noreply]

Author: aaugustin
Date: 2012-02-07 10:46:29 -0800 (Tue, 07 Feb 2012)
New Revision: 17462

Modified:
   django/trunk/django/core/management/__init__.py
   django/trunk/docs/ref/django-admin.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed #11745 -- Grouped commands by application in the output of `manage.py 
help`. Made 'version' consistent with 'help' while I was in the area, and added 
tests. Thanks Jannis for the feedback and review.


Modified: django/trunk/django/core/management/__init__.py
===
--- django/trunk/django/core/management/__init__.py 2012-02-06 02:00:19 UTC 
(rev 17461)
+++ django/trunk/django/core/management/__init__.py 2012-02-07 18:46:29 UTC 
(rev 17462)
@@ -1,3 +1,4 @@
+import collections
 import os
 import sys
 from optparse import OptionParser, NO_DEFAULT
@@ -5,6 +6,7 @@
 import warnings
 
 from django.core.management.base import BaseCommand, CommandError, 
handle_default_options
+from django.core.management.color import color_style
 from django.utils.importlib import import_module
 
 # For backwards compatibility: get_version() used to be in this module.
@@ -209,16 +211,32 @@
 self.argv = argv or sys.argv[:]
 self.prog_name = os.path.basename(self.argv[0])
 
-def main_help_text(self):
+def main_help_text(self, commands_only=False):
 """
 Returns the script's main help text, as a string.
 """
-usage = ['',"Type '%s help ' for help on a specific 
subcommand." % self.prog_name,'']
-usage.append('Available subcommands:')
-commands = get_commands().keys()
-commands.sort()
-for cmd in commands:
-usage.append('  %s' % cmd)
+if commands_only:
+usage = sorted(get_commands().keys())
+else:
+usage = [
+"",
+"Type '%s help ' for help on a specific 
subcommand." % self.prog_name,
+"",
+"Available subcommands:",
+]
+commands_dict = collections.defaultdict(lambda: [])
+for name, app in get_commands().iteritems():
+if app == 'django.core':
+app = 'django'
+else:
+app = app.rpartition('.')[-1]
+commands_dict[app].append(name)
+style = color_style()
+for app in sorted(commands_dict.keys()):
+usage.append("")
+usage.append(style.NOTICE("[%s]" % app))
+for name in sorted(commands_dict[app]):
+usage.append("%s" % name)
 return '\n'.join(usage)
 
 def fetch_command(self, subcommand):
@@ -340,12 +358,15 @@
 subcommand = 'help' # Display help if no arguments were given.
 
 if subcommand == 'help':
-if len(args) > 2:
-self.fetch_command(args[2]).print_help(self.prog_name, args[2])
-else:
+if len(args) <= 2:
 parser.print_lax_help()
 sys.stdout.write(self.main_help_text() + '\n')
-sys.exit(1)
+elif args[2] == '--commands':
+sys.stdout.write(self.main_help_text(commands_only=True) + 
'\n')
+else:
+self.fetch_command(args[2]).print_help(self.prog_name, args[2])
+elif subcommand == 'version':
+sys.stdout.write(parser.get_version() + '\n')
 # Special-cases: We want 'django-admin.py --version' and
 # 'django-admin.py --help' to work, for backwards compatibility.
 elif self.argv[1:] == ['--version']:

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2012-02-06 02:00:19 UTC (rev 
17461)
+++ django/trunk/docs/ref/django-admin.txt  2012-02-07 18:46:29 UTC (rev 
17462)
@@ -47,12 +47,17 @@
 Getting runtime help
 
 
-.. django-admin-option:: --help
+.. django-admin:: help
 
-Run ``django-admin.py help`` to display a list of all available commands.
-Run ``django-admin.py help `` to display a description of the
-given command and a list of its available options.
+Run ``django-admin.py help`` to display usage information and a list of the
+commands provided by each application.
 
+Run ``django-admin.py help --commands`` to display a list of all available
+commands.
+
+Run ``django-admin.py help `` to display a description of the given
+command and a list of its available options.
+
 App names
 -
 
@@ -63,9 +68,9 @@
 Determining the version
 ---
 
-.. django-admin-option:: --version
+.. django-admin:: version
 
-Run ``django-admin.py --version`` to display the current Django version.
+Run ``django-admin.py version`` to display the current Django version.
 
 Examples of output::
 

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:  fixed
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  help color django-   |  Patch needs improvement:  0
  admin manage.py|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [17462]:
 {{{
 #!CommitTicketReference repository="" revision="17462"
 Fixed #11745 -- Grouped commands by application in the output of
 `manage.py help`. Made 'version' consistent with 'help' while I was in the
 area, and added tests. Thanks Jannis for the feedback and review.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17431: Allow PasswordResetForm subclasses full control over email message to send

[Django]

#17431: Allow PasswordResetForm subclasses full control over email message to 
send
--+
 Reporter:  ejucovy   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ejucovy):

 Replying to [comment:2 anonymous]:
 > My need is to include an additional variable in the context that is used
 to render the email template. I don't see that the patch provided supports
 that use case?

 Where will your extra context variable be coming from?

 If it's something that you can derive without access to a request, then
 you can just inject it into the context in your overridden
 `construct_email` method.  Likewise if it's something derived from
 `request.POST` then `self.data` will contain the full POSTed form, and you
 can inject your needed variable in `construct_email`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17431: Allow PasswordResetForm subclasses full control over email message to send

[Django]

#17431: Allow PasswordResetForm subclasses full control over email message to 
send
--+
 Reporter:  ejucovy   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 My need is to include an additional variable in the context that is used
 to render the email template. I don't see that the patch provided supports
 that use case?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17591: USSocialSecurityNumberField doesn't validate the same when entered without hypens

[Django]

#17591: USSocialSecurityNumberField doesn't validate the same when entered 
without
hypens
-+-
 Reporter:  aaron.l.madison@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor  | Triage Stage:  Accepted
  ussocialsecuritynumberfield|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by aaron.l.madison@…):

 sorry for the spam... accidentally posted the patch and my comment as
 anonymous.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17591: USSocialSecurityNumberField doesn't validate the same when entered without hypens

[Django]

#17591: USSocialSecurityNumberField doesn't validate the same when entered 
without
hypens
-+-
 Reporter:  aaron.l.madison@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor  | Triage Stage:  Accepted
  ussocialsecuritynumberfield|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by anonymous):

 Thanks for your feedback. I've attached another patch.

 To me the small methods are much less about DRY and much more about
 readability. A method that clearly says what it does doesn't need a
 comment to say what it does. Personal preference I'm sure.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17459: Subquery fails across multiple databases

[Django]

#17459: Subquery fails across multiple databases
-+-
 Reporter:  dgouldin |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lrekucki):

 * cc: lrekucki@… (added)
 * stage:  Unreviewed => Design decision needed


Comment:

 I'm not sure calling {{{db_for_read(Foo)}}} will help here even if we
 include a hint like {{{subquery_of=Bar}}}. If parent query is already
 bound to some db, the only thing the router can do for subquery is either
 return the same DB (thus allowing the subquery to perform) or throw an
 exception because it's impossible to perform the query (i'm still -1 on
 doing list() implicitly).

 How about adding a new method to the router {{{allow_subquery}}} (which
 would basically work the same as {{{allow_relation}}}, but for models
 instead of instances) ?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  help color django-   |  Patch needs improvement:  0
  admin manage.py|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  help color django-   |  Patch needs improvement:  0
  admin manage.py|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 I've also made the implementation of version / --version consistent with
 help / --help while I was there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  help color django-   |  Patch needs improvement:  0
  admin manage.py|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0


Comment:

 I'm uploading a new patch with the implementation discussed on IRC with
 jezdez, tests and docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16656: Make urlize TLDs configurable

[Django]

#16656: Make urlize TLDs configurable
-+-
 Reporter:  ralphje  |Owner:  anonymous
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


Comment:

 I expanded the list of TLDs from the arbitrary choice of `com|net|org` to
 the slightly less arbitrary choice of the seven original gTLDs
 `com|edu|gov|int|mil|net|org`. I had to draw the line somewhere and I
 don't want the debate on this list to turn into bikeshedding.

 That said, I just read the list of comments ahead again, and I agree that
 it could make sense to add a setting...

 I'm going to leave this ticket open, could you provide a patch with tests
 and docs ?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16656: Make urlize TLDs configurable

[Django]

#16656: Make urlize TLDs configurable
-+-
 Reporter:  ralphje  |Owner:  anonymous
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ralphje):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 I don't really see why we wouldn't add a setting for the default TLDs,
 since there's absolutely no reason why .com, .net and .org are included,
 while .info isn't, for example. I know that .info is not one of the
 original gTLDs, but for any 'mortal' user, this is just random. He would
 see that his .com's are automatically urlized, but his .info's aren't.

 Allowing this to be customized would furthermore help internationalization
 of this filter and would 'explain' why some TLDs were included and some
 weren't (or at least leave the explaining to the developer). You (more
 specifically, a developer using this setting) could also choose to not
 include any TLD, since that would be even more consistent.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by ramiro:

Old description:

> After a very standard and minor release, our Apache/Nginx/Django/wsgi
> setup ceased to function with the only error "Premature end of script
> headers: django.wsgi" in the apache log.
> There is no expat problem (checked with sample wsgi app with and without
> that module include). The server was working fine. The codebase was
> updated slightly and apache restarted when the horrors began. The
> codebase was rolled back and still the problem persists.
> Below are my wsgi file, apache config and a dump from running wsgi under
> the debuger.
>
> I will have to rebuilt the server very soon, as the problem just won't go
> away. I am holding off in case anyone here finds this interesting and
> needs more information.
>
> The system is Debian Squeeze, Apache/2.2.16 (Debian), Python 2.6.4,
> Django 1.3.1. modwsgi 3.3-2
> All packages are installed via apt-get/pip. Another server with similar
> setup doesn't exhibit the problem.
>

> '''wsgi file''':
> import sys
> import os
>
> sys.path.append('/home/app/')
> sys.path.append('/home/app/topmodule/')
>
> os.environ['DJANGO_SETTINGS_MODULE'] = 'app.settings'
> os.environ["CELERY_LOADER"] = "django"
>
> import app.settings
> import django.core.handlers.wsgi
>
> application = django.core.handlers.wsgi.WSGIHandler()
>

> '''apache config:'''
> WSGIScriptAlias / /home/app/topmodule/django.wsgi
> WSGIDaemonProcess app user=app group=app processes=6 threads=1
> WSGIProcessGroup app
> Have also tried with :
> WSGIApplicationGroup %{GLOBAL}
>
> '''Django Middleware''':
> 'django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'glowconsole.middleware.ViewNameMiddleware',
> 'django.middleware.gzip.GZipMiddleware'
>

> Debugger dump  when running apache2 -X with the pdb debugger wrapper
> (also here: http://paste.pocoo.org/show/546803/)
> batman:/home/harel# /usr/sbin/apache2 -X
> ['/usr/local/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg',
> '/usr/local/lib/python26.zip', '/usr/local/lib/python2.6',
> '/usr/local/lib/python2.6/plat-linux2', '/usr/local/lib/python2.6/lib-
> tk', '/usr/local/lib/python2.6/lib-old', '/usr/local/lib/python2.6/lib-
> dynload', '/usr/local/lib/python2.6/site-packages',
> '/usr/local/lib/python2.6/site-packages/PIL', '/home/glowconsole/',
> '/home/glowconsole/glowconsole/', '/usr/local/lib/python2.6/site-
> packages/django']
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(240)__call__()
> -> from django.conf import settings
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(244)__call__()
> -> if self._request_middleware is None:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(245)__call__()
> -> self.initLock.acquire()
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(246)__call__()
> -> try:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(247)__call__()
> -> try:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(249)__call__()
> -> if self._request_middleware is None:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(250)__call__()
> -> self.load_middleware()
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(256)__call__()
> -> self.initLock.release()
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(258)__call__()
> -> set_script_prefix(base.get_script_name(environ))
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(259)__call__()
> -> signals.request_started.send(sender=self.__class__)
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(260)__call__()
> -> try:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(261)__call__()
> -> try:
> (Pdb) n
> > /usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py(262)__call__()
> -> 

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Replying to [comment:1 charettes]:
 > Which backend are you using? I'm asking because I know MySQL has issues
 with those kind of ids.

 Indeed, I'm using MySQL. good guess :)
 MySQL does create an object with a random id when given 0. Is that to say
 that this issue is to be considered as a mysql bug?
 Shouldn't Django work that around?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+
 Reporter:  jcspray@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * version:  1.3 => SVN
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 There is a flag called 'requires_model_validation' that commands can unset
 to not require validation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
-+-
 Reporter:  harel@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi apache  | Triage Stage:
  segfault   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 apologies for not using wiki formatting. noticed too late after posting
 and cannot edit

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17658: Django wsgi.py segfaults Apache

[Django]

#17658: Django wsgi.py segfaults Apache
---+--
 Reporter:  harel@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:  wsgi apache segfault
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 After a very standard and minor release, our Apache/Nginx/Django/wsgi
 setup ceased to function with the only error "Premature end of script
 headers: django.wsgi" in the apache log.
 There is no expat problem (checked with sample wsgi app with and without
 that module include). The server was working fine. The codebase was
 updated slightly and apache restarted when the horrors began. The codebase
 was rolled back and still the problem persists.
 Below are my wsgi file, apache config and a dump from running wsgi under
 the debuger.

 I will have to rebuilt the server very soon, as the problem just won't go
 away. I am holding off in case anyone here finds this interesting and
 needs more information.

 The system is Debian Squeeze, Apache/2.2.16 (Debian), Python 2.6.4, Django
 1.3.1. modwsgi 3.3-2
 All packages are installed via apt-get/pip. Another server with similar
 setup doesn't exhibit the problem.


 '''wsgi file''':
 import sys
 import os

 sys.path.append('/home/app/')
 sys.path.append('/home/app/topmodule/')

 os.environ['DJANGO_SETTINGS_MODULE'] = 'app.settings'
 os.environ["CELERY_LOADER"] = "django"

 import app.settings
 import django.core.handlers.wsgi

 application = django.core.handlers.wsgi.WSGIHandler()


 '''apache config:'''
 WSGIScriptAlias / /home/app/topmodule/django.wsgi
 WSGIDaemonProcess app user=app group=app processes=6 threads=1
 WSGIProcessGroup app
 Have also tried with :
 WSGIApplicationGroup %{GLOBAL}

 '''Django Middleware''':
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'glowconsole.middleware.ViewNameMiddleware',
 'django.middleware.gzip.GZipMiddleware'


 Debugger dump  when running apache2 -X with the pdb debugger wrapper (also
 here: http://paste.pocoo.org/show/546803/)
 batman:/home/harel# /usr/sbin/apache2 -X
 ['/usr/local/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg',
 '/usr/local/lib/python26.zip', '/usr/local/lib/python2.6',
 '/usr/local/lib/python2.6/plat-linux2', '/usr/local/lib/python2.6/lib-tk',
 '/usr/local/lib/python2.6/lib-old', '/usr/local/lib/python2.6/lib-
 dynload', '/usr/local/lib/python2.6/site-packages',
 '/usr/local/lib/python2.6/site-packages/PIL', '/home/glowconsole/',
 '/home/glowconsole/glowconsole/', '/usr/local/lib/python2.6/site-
 packages/django']
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(240)__call__()
 -> from django.conf import settings
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(244)__call__()
 -> if self._request_middleware is None:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(245)__call__()
 -> self.initLock.acquire()
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(246)__call__()
 -> try:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(247)__call__()
 -> try:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(249)__call__()
 -> if self._request_middleware is None:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(250)__call__()
 -> self.load_middleware()
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(256)__call__()
 -> self.initLock.release()
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(258)__call__()
 -> set_script_prefix(base.get_script_name(environ))
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(259)__call__()
 -> signals.request_started.send(sender=self.__class__)
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(260)__call__()
 -> try:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(261)__call__()
 -> try:
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(262)__call__()
 -> request = self.request_class(environ)
 (Pdb) n
 > /usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py(272)__call__()
 -> response = self.get_response(request)
 (Pdb) l
 267 'status_code': 400,
 268 }
 269 )
 270 response = http.HttpResponseBadRequest()
 271 else:
 272  -> response = self.get_response(request)
 273  

Re: [Django] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pmartin):

 I research the problem. And these queries are different:

 {{{
 User.objects.exclude(groups__in=[g1.pk])
 User.objects.exclude(Q(groups__in=[g1.pk]))
 }}}

 But, however these are equals:


 {{{
 User.objects.exclude(groups__in=[g1.pk])
 User.objects.filter(~Q(groups__in=[g1.pk]))
 User.objects.exclude(~~Q(groups__in=[g1.pk]))
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name attribute

[Django]

#17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name
attribute
+--
 Reporter:  andreyfedoseev  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by andreyfedoseev):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name attribute

[Django]

#17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name
attribute
+
 Reporter:  andreyfedoseev  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 When extracting data from existing model instance `ModelForm` ignores
 `to_field_name` attribute of `ModelMultipleChoiceField` fields and always
 extracts values as a list of primary keys (see
 
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py?rev=17434#L127)

 One of the problems caused by this behaviour is that options in multiple
 select widget are not selected. Here's a small test case to illustrate
 this:

 {{{
 # models.py

 from django.db import models


 class Foo(models.Model):

 slug = models.CharField(max_length=40, unique=True)
 title = models.CharField(max_length=40, unique=True)


 class Bar(models.Model):

 foos = models.ManyToManyField(Foo)

 }}}


 {{{
 # tests.py

 from django.test.testcases import TestCase
 from django import forms
 from models import Foo, Bar


 class TestModelMultipleChoiceWithFieldName(TestCase):

 def setUp(self):
 self.instance = Bar.objects.create()

 self.instance.foos.add(Foo.objects.create(title="Spam",
 slug="spam"))
 self.instance.foos.add(Foo.objects.create(title="Ham",
 slug="ham"))
 self.instance.foos.add(Foo.objects.create(title="Eggs",
 slug="eggs"))


 def test_without_field_name(self):

 class Form(forms.ModelForm):

 foos = forms.ModelMultipleChoiceField(Foo.objects.all())

 class Meta:
 model = Bar

 form = Form(instance=self.instance)

 self.assertEquals(
 str(form["foos"]),
 '\n'
 'Spam\n'
 'Ham\n'
 'Eggs\n'
 ''
 )

 def test_with_field_name(self):

 class Form(forms.ModelForm):

 foos = forms.ModelMultipleChoiceField(Foo.objects.all(),
 to_field_name="slug")

 class Meta:
 model = Bar

 form = Form(instance=self.instance)

 # Fails! Options aren't selected.
 self.assertEquals(
 str(form["foos"]),
 '\n'
 'Spam\n'
 'Ham\n'
 'Eggs\n'
 ''
 )

 }}}

 I am preparing a patch now.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+
 Reporter:  jcspray@…|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The collectstatic command, like all management commands, gets a call to
 self.validate() which requires a database to be up and running.  This is
 annoying, because this command has no need for the database at all, and
 may well be run during packaging/deployment where a database may not be
 present.

 Although hypothetically the STATICFILES_STORAGE setting could refer to
 something that stores static files in a database, the behaviour should be
 made more convenient for the default.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh

[Django]

#17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh
---+
 Reporter:  akaihola   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  geodjango postgis  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by akaihola):

 There's also some discussion about these scripts in #13340.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13340: patch for updating postgis template script for ubuntu 10.04

[Django]

#13340: patch for updating postgis template script for ubuntu 10.04
--+
 Reporter:  neskiem@… |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by akaihola):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 Replying to [comment:3 neskiem@…]:
 > I wonder if the package maintainers would consider putting this script
 in itself, and they would maintain it, because they know exactly where
 those files are going to be, because they have the README and change it
 when necessary.

 Do you mean distribution package maintainers?

 A lot of developers on Debian-based systems install Django from a tarball
 or from the repository instead of using distribution packages. For this
 reason, I think these scripts belong to the repository and not only
 distribution packages.

 See also #17584 for an updated script which supports Ubuntu 11.10 and
 derivatives.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17655: having a forward option for tickets

[Django]

#17655: having a forward option for tickets
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by russellm):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Firstly, If you have a question about Trac, you don't ask it on Trac; you
 ask on the mailing list. Trac is for tracking the progress on solving
 identified and verified problems.

 Secondly, I have absolutely no idea what you're referring to, so I can't
 suggest how to turn this ticket into an actionable item.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.